Productionize an AI-generated codebase (Lovable, Bolt, v0, Replit)

The realistic gap between an AI-generated prototype and a production-grade system, axis by axis:

The prototype is 60–90% of the UI and happy-path functionality. It is 10–40% of what an enterprise customer evaluates. Closing the gap is the work.

Week 1 is the audit + scope. We do not write production code until we have a shared map of what is and isn't there.

The audit:

1. Walk the 12 axes above. Score each as "demo", "in progress", or "production". One-page scorecard per axis.
2. Stand up the production observability layer (Helicone, LiteLLM, Maxim, or fast-litellm) so we can see cost + latency + errors from day 1.
3. Stand up a 1-day threat model — what data leaves the building, what credentials are in scope, what an attacker can do with the current code as-is.
4. Stand up the secrets manager (1Password CLI, Doppler, Vault). All current and future credentials go through it.
5. Set up a single source-of-truth environment file. No more .env.local drift across laptops.

End of week 1: a 12-axis scorecard, a documented threat model, a working observability layer, and a named in-house owner per axis.

Auth is the first thing an enterprise customer evaluates and the first thing an AI-generated prototype gets wrong. Weeks 2–3 are auth + data, in parallel.

Auth (if you're using a third-party auth like Supabase Auth, Clerk, or Auth0):

• Replace the dev "test user" with a real email + password flow with proper validation, password reset, account recovery.
• Add SSO (SAML or OIDC) for the first enterprise customer. Most teams buy Clerk or WorkOS for this; we wire the integration.
• Add MFA. SMS is the floor; TOTP is the bar; passkeys are the future.
• Add RBAC. Default role is "user"; add "admin" and "owner" with a documented role hierarchy.
• Wire audit logs: every login, every role change, every permission grant. Same observability stack as the rest of production.

Data (if you're using Supabase, Postgres, or a managed DB):

• Turn RLS on for every user-facing table. Every table. The single most common production-readiness miss.
• Write migrations, not schema push. Migrations are version-controlled, reversible, and have a deploy + rollback story.
• Stand up automated backups with a tested restore. "We have backups" is not a backup until you've restored from one.
• Wire PII redaction into any prompt that touches user data. (Same prompt-data gateway as the AI code security engagement.)
• Set per-team cost budgets in the dashboard. Production Supabase bills grow fast; surface them before they surprise finance.

End of week 3: SSO + MFA + RBAC + audit log, every user-facing table behind RLS, migrations in version control, backups tested, cost dashboards live.

Weeks 4–5 are the runtime story: APIs, observability, error handling, performance.

APIs:

• Versioned. /v1/ in the path, with a documented deprecation policy.
• Rate-limited. Per-IP, per-user, per-endpoint. The limits are in a config file, not hardcoded.
• Idempotent on writes. Idempotency keys on POST + DELETE. The same request sent twice produces the same result.
• Documented. OpenAPI / AsyncAPI specs checked into the repo. Generated client SDKs where appropriate.
• Error contracts. Stable error codes, structured error bodies, no leaked stack traces.

Observability:

• Per-route: latency (p50, p95, p99), error rate, throughput.
• Per-business-KPI: cost per request, cost per user, cost per conversion.
• SLOs documented per route (e.g. "p95 < 500ms, error rate < 0.1%").
• Alerting on SLO breach, not on raw metrics. Page the on-call only when the SLO is in danger.

Error handling:

• Structured logging. JSON, not prose. Queryable like a database.
• Error tracking. Sentry or equivalent, with source maps, with the user + request context.
• User-facing error states. Never a stack trace; always "something went wrong, here's what to do next".

Performance:

• Cold-start test. The first request after deploy is the slow one — measure it.
• Scale test. Synthetic load that mimics 10x the current production traffic. Where does it break?
• CDN for static assets. Cache-Control headers. Image optimization.
• Database indexes. EXPLAIN ANALYZE on the top 10 queries. The slow queries are almost always the ones you don't know about.

End of week 5: versioned + rate-limited + idempotent APIs, SLOs documented and alerting, structured logging + error tracking, scale test run.

Weeks 6–7 are the security and compliance work. The auditor (or the enterprise customer's security team) is going to ask; better to have the answers than scramble.

Security:

• AI-aware SAST in CI. Catches hallucinated packages, missing test files, license violations, suspicious imports. (Snyk with AI rules, Semgrep, or a custom rule.)
• Secret scan in CI. gitleaks, TruffleHog. Every PR.
• Dependency audit. npm audit / pip-audit / equivalent. Every PR.
• Penetration test. Even a 2-day internal pen test catches the obvious stuff.
• Threat model. A one-page document. Updated annually.

Compliance:

• SOC 2 evidence trail. Who has access, what changed, when, why. Audit log + change log + access reviews.
• GDPR: data export, right to erasure, cookie consent, DPA with every sub-processor.
• HIPAA (if healthcare): BAA with every sub-processor, audit logs on every PHI access, encryption at rest and in transit.
• CCPA, state laws, anything the customer is going to ask about. The compliance matrix is a one-page document.

End of week 7: AI-aware SAST + secret scan + dependency audit in CI, threat model + pen test report in the repo, compliance matrix one-pager, audit evidence trail documented.

Week 8 is the handoff. The engagement is over; the work is not.

The handoff:

1. Runbook per axis. One page per axis: what is the work, who owns it, what to do when it breaks, what to add next.
2. One named internal owner per axis. They were in the room during the engagement; they own the system after.
3. A 12-axis scorecard marked "production" for every axis. The single artifact the team points to when someone asks "are we production-ready?".
4. A 90-day roadmap. What's not done, what's not production-grade yet, what to add when the team has time. Sequenced by impact.
5. A monthly check-in for the first 3 months. We don't disappear; we just check in once a month to make sure nothing's regressed.

End of week 8: the system is production-grade, the runbook is in the repo, the in-house owners are named, the 90-day roadmap is written.

What you operate after the engagement:

• The codebase. In your repo, in your preferred language, in your version control.
• The production-grade auth, data, API, observability, security, compliance layers. All yours.
• The runbook, the 12-axis scorecard, the threat model, the compliance matrix. All in your repo or your wiki.
• The named in-house owners per axis. They were in the room; they own the system.

What we don't do:

• We don't operate a managed service. We don't have a dashboard you log into. The system is yours.
• We don't retain credentials. After handoff, your secrets manager is the only place they live.
• We don't disappear entirely — the monthly check-in for the first 3 months is part of the engagement — but we are explicitly set up to hand off, not to create dependency.

Outcome pricing: we keep 10% of first-year production revenue uplift, or fixed scope if you prefer. The point of outcome pricing is that we win when the engagement ships a system that earns.

Three situations where the right answer is to rewrite, not to productionize:

1. The prototype is a UX mockup, not real code. If "the prototype" is a Figma or a ClickUp wireframe, there's nothing to harden. The work is build, not harden.
2. The prototype uses a deprecated or abandoned framework. If Lovable or Bolt generated code against a framework that's no longer maintained, the right answer is to migrate to a current framework first, then harden. Hardening dead code is wasted work.
3. The team doesn't want the codebase. If the team sees the AI-generated prototype as a demo to learn from, not a codebase to ship, the right answer is to start fresh with the team's preferred stack and the lessons learned. Forcing productionization on a codebase the team resents is a bad engagement for everyone.

If any of these is true, we will tell you on the 30-minute technical call and not take the engagement. The 3–8 week productionization is for teams that want the codebase to ship.

When to do this yourself, when to hire: