The prototype demos beautifully. It has real functionality, a clean UI, and it was built in days rather than months. It also, in most cases we've seen, has no real authentication, a data model that only works because nobody has tried to break it yet, zero observability, and no defined path from "works on my machine, for me, in a demo" to "works for real users, who will do things you didn't anticipate."
None of that is a criticism of the tool that built it. AI-builder tools like Lovable, Bolt.new, v0 and their peers are genuinely good at the job they're built for: validating an idea fast, in front of users or investors, before committing real engineering budget. The problem is not the tool. It's the gap between "the tool got me here" and "this can now serve real users," which is routinely underestimated because the demo looks finished.
What "production-ready" actually requires
Four things, consistently, in roughly this order of how often they're missing:
Real authentication
Prototype auth is frequently a stubbed session, a single hardcoded test account, or an auth provider wired up just enough to demo the happy path. Production auth means real session management, password or SSO flows that handle the actual failure cases (expired tokens, concurrent sessions, account recovery), and an access-control model that maps to who should actually be able to see what, not "everyone who's logged in can see everything," which is where most prototypes land by default.
A data model that holds up under real use
Prototype data models are optimised for "the demo flow works," not for constraints, referential integrity, or a schema that can evolve without a rewrite. The tell is usually loosely-typed fields doing the job of what should be several properly related tables, and no migration story at all, because the prototype was never expected to need one. Retrofitting this after real user data exists is meaningfully harder than designing it correctly before launch, which is the single biggest argument for an audit before real users arrive rather than after.
Observability
A demo doesn't need to tell you when it's failing, because you're watching it while it runs. Production software fails when nobody's watching, and the only way you find out is if the system tells you: logging, error tracking, uptime monitoring, and alerting on the failure modes that actually matter for your specific product. Prototypes built for demos almost never have any of this, because there was never a "3am, nobody's looking" scenario to design for.
A migration path
The quiet one. "Production-ready" isn't a single event. It's the first of many changes the system will need to survive. A prototype with no clear separation between its demo-optimised implementation and a maintainable architecture underneath makes every subsequent change harder than it needs to be. This is the difference between a system that gets easier to extend over time and one that gets more fragile with every feature added.
Retrofit or rebuild: the actual decision
This is the question that matters more than any generic checklist, and it doesn't have a universal answer:
Retrofit tends to make sense when the prototype's core logic and UX genuinely validated the idea, and the gaps are contained to the four areas above, and addressable without touching the parts that work.
Rebuild tends to make sense when the prototype's value was in proving the idea, not the implementation; when the underlying code would need to change so extensively to meet the four requirements above that treating the prototype as a working specification, and building the production version properly, is genuinely faster than patching around what's there.
Neither answer is more virtuous than the other. The mistake is not asking the question explicitly and defaulting to "just keep building on what we have" because that's the path of least short-term resistance. See what custom software actually costs for the cost bands either path tends to land in, since retrofit and rebuild are priced differently and it's worth knowing both before deciding.
What we actually look at in an audit
A production-readiness audit isn't a vague code review. It's a defined process against the four requirements above:
- Authentication and access-control review against real threat scenarios, not just the happy path.
- Data model review: what's there, what's missing, and what a proper migration would involve.
- Observability gap analysis: what you'd know if this failed at 3am, versus what you'd need to know.
- A written retrofit-vs-rebuild recommendation, scoped and costed, so you have a decision to make rather than a vague sense of "there's work to do."
We follow the same thirteen-phase process for whatever comes next, whether that's a retrofit or a rebuild. The audit's job is to tell you honestly which one you're looking at.
Fixed price, two weeks, no ambiguity
The audit is a fixed $4,500, scope agreed before we start, findings report delivered within two weeks. You get a written, actionable answer to "what's actually here and what would it take", usable whether you proceed with us, elsewhere, or not at all. Book a readiness audit, or see what we build if you're earlier than that and want the fuller picture first.
Common questions
Rarely without real work first. These tools are excellent for demos and for validating an idea fast, which is exactly what they're built for. But a working demo and a production system are different engineering artifacts, and the gap between them is usually auth, data modelling, observability and a migration path, not polish.
It depends on how much of the demo's logic and UX validated the actual idea versus how much of the underlying implementation is usable as-is. A production-readiness audit answers this directly rather than guessing. The honest answer is sometimes "retrofit is cheaper," and sometimes it's "the fastest path to production is treating the prototype as a spec and rebuilding the implementation."
AI-builder tools optimise for getting something on screen fast, which often means data is stored in whatever shape made the demo work: loosely typed, no real constraints, no migration strategy, sometimes no persistence beyond a session. That's fine for a demo. It breaks the moment real users create real data you're responsible for.
Yes, precisely because you're not sure. The audit's output is a written findings report you can act on with us or take elsewhere. It's scoped to answer "what's actually here and what would it take," not to lock you into a larger engagement.