AI-Generated Code: From Demo to Production
Last verified: October 2026· engagement
You built the prototype in a weekend with Lovable, Bolt, v0, or Replit Agent. We take it to production — auth (SSO + RBAC), data (RLS + migrations + backups), APIs (versioning + rate limits), observability (cost + latency + errors), and the security + compliance the demo doesn't have. Same engineers we use for the AI-coding rollout and LLM cost work.
- Outcome
- A documented, production-grade codebase your team owns
- Timeline
- 3–8 weeks
- Pricing
- $25–80k fixed, or 10% of first-year production revenue uplift
- Buyer
- CTO, VP Eng, Head of Platform (any team that shipped a Lovable / Bolt / v0 / Replit prototype)
The problem
You built a working prototype in a weekend with Lovable, Bolt, v0, or Replit Agent. The demo is impressive. Production is a different problem: SSO + RBAC + RLS + migrations + backups + rate limits + idempotency + monitoring + alerts + incident response + SOC 2. None of that ships by default — and most of the AI-generated code assumes a single trusted user on localhost.
What we do
- Audit the prototype against a 12-axis production-readiness rubric (auth, data, APIs, observability, security, cost, compliance, devops, reliability, performance, accessibility, error handling).
- Harden auth: SSO, MFA, RBAC, session handling, password reset, account recovery, audit logs.
- Harden the data layer: RLS policies (or self-hosted Postgres + your own auth), migrations, backups, scaling, PII redaction.
- Wire observability: per-route cost, latency, error rate, and SLO dashboards — wired into the team's existing stack, not a separate tool.
- Stand up the security + compliance the demo doesn't have: prompt-data gateway, AI-aware SAST, SOC 2 evidence trail.
How it fits together
What you get
Built on our open source
fast-litellm — Rust acceleration for LiteLLM — faster connection pooling, rate limiting, and memory-intensive workloads.
What the prototype is missing, specifically
Prototypes built with app generators tend to fail in the same places, and it is not because the generated code is bad — it is because the generator optimised for something working quickly, which is a genuinely different objective from something surviving contact with real users. The recurring gaps are authentication that handles the happy path only, database access with no row-level policy so any authenticated user can read anything, secrets committed or embedded client-side, no migration history so schema changes are manual and irreversible, and no backups at all.
We start with a readiness pass across the axes that determine whether this is a small job or a large one: auth and session handling, authorisation and data boundaries, secrets, schema and migrations, backups and restore, input validation, rate limiting, error handling and logging, dependency provenance, tests, deployment repeatability, and observability. The output is a ranked list where the ranking is by exposure rather than effort, so the first week closes whatever would actually hurt you if a real user arrived tomorrow.
The judgement call that matters most is what to keep. There is a strong temptation to rewrite, and it is usually wrong: the prototype encodes real product decisions that took iteration to find, and throwing it out means rediscovering them. The usual outcome is that the data layer and the auth layer get rebuilt properly, the interface and the product logic largely survive with tests added around them, and the result is something your team can own rather than something that merely works.
When this is not the right engagement
Hardening is worth doing once the product has stopped moving underneath it. It is a poor fit when:
- The prototype has not found its product yet. Hardening something you are about to change fundamentally is wasted money; keep iterating first.
- You want it rewritten from scratch in a different stack. That is a build, not a productionization, and should be scoped as one.
- There is no one to own it afterwards. We hand over a codebase and runbooks; someone on your side has to take them.
What “done” means
These are written into the agreement before work starts, so you, your finance team and procurement can see the finish line up front.
Acceptance
- The production-readiness checklist agreed at kickoff passes, item by item.
- A deploy and a rollback are demonstrated in your environment.
- Auth, data boundaries and secrets handling pass the agreed security review.
- Your team owns the repo, the pipeline and the runbook.
Not included
- New product features beyond the agreed launch scope.
- Ongoing hosting or on-call after handover, unless contracted separately.
- Formal certification (SOC 2, ISO 27001); we produce the engineering evidence, not the audit.
What we need from you
- The app repository and current hosting accounts.
- A named product owner who can make scope calls within a day.
- The launch date and the requirements behind it (customer, security review, investor).
Common questions about this engagement
Do you work under NDA?
Yes — we sign your mutual NDA before any data or repo access. For audits we prefer read-only access to start; for builds we work in a clean repo under your ownership.
Will we own what you ship?
Always. You own the code, the runbooks, the dashboards. We are explicitly set up to hand off and transition out, not to create dependency.
Vendor-agnostic — what does that mean in practice?
We integrate with what you already run — OpenAI, Anthropic, open-weight models on your cloud, your CI/CD, your observability stack. If a hosted vendor solves it, we will not reinvent it; if a self-hosted tool is the right answer, we will not pretend the hosted one is.
How is this different from a Big Four consulting deck?
We are the engineers doing the work, not analysts handing recommendations to a different team. The deliverable is working software in your repo, not a slide deck.
Can you work with our in-house AI team instead of replacing them?
Yes — most of our engagements pair with an internal owner and ramp them up to run the system after we leave. Many of our best engagements start with "we hired an AI team, help us get them productive."
Will you rewrite our prototype?
Usually not, and the temptation to is worth resisting. The prototype encodes real product decisions that took iteration to find, and throwing it out means rediscovering them at your expense. The typical outcome is that the data layer and the auth layer get rebuilt properly, the interface and the product logic largely survive with tests added around them, and you end up owning something rather than merely possessing something that works.
What should we check ourselves before calling you?
Two things, and both take about an hour. Sign in as one test user and try to read another user's data through the API rather than the interface, which tells you whether row-level access is actually enforced. Then search the repository and the built client bundle for anything resembling a key or token. Those two findings account for most genuine emergencies in this category, and if either fails it is worth closing before planning anything else.
Guides for this work
Is your codebase ready for AI agents?
Agents don't fail randomly on a repo — they fail predictably on the same things that slow down human engineers: fuzzy boundaries, missing tests, undocumented conventions. Readiness is just those weaknesses paid down deliberately.
Agentic codingWhat is agentic coding?
Agentic coding is letting an AI coding agent plan, edit across files, run tools and tests, and iterate in a loop toward a goal — powerful for the first 80% of a change, and quietly expensive on the last 20% if you skip standards and review.
Let’s scope it on a call
Thirty minutes with an engineer. We’ll tell you straight whether this is the right first move for your team.