In short: Going from prototype to production is not more coding, it is deciding identity, data, payments, integrations and security before the code is written, because those five are what break first.
You did not build your business by doing everything yourself. So it is worth asking why you are trying to build your software that way.
Most of the projects we are asked to rescue started well. Someone had a genuinely good idea and built a prototype with no-code tools, AI coding assistants, or a couple of developers. It demoed well. It may even have had paying users. Then real-world complexity arrived: logins stopped behaving, the database became painful to change, payments did not reconcile, a third-party API broke without warning, pages got slow, and security turned into an open question.
None of that means the original build was stupid. It means the thing that was built was a prototype, and it is now being asked to do the job of production software. Getting from prototype to production is the part almost nobody scopes honestly.
What is the difference between a prototype and production software?
A prototype proves that an idea can work. Production software proves it can keep working for people you have never met, with money attached, while you change it. The prototype answers a product question. Production answers engineering questions: identity, data integrity, payment state, integration failure, security and load.
That distinction matters because the two are built differently from the first day. You cannot reliably reach the second by adding features to the first.
1. Authentication is where prototypes fail first
Sign-up and login are the easiest thing in the world to demo and among the harder things to get right. A prototype usually has one kind of user, one session, and a happy path.
What it looks like in production
- Users are logged out at random because sessions were never designed to persist or refresh properly
- There is no real notion of roles, so any account that can see the admin screen can use it
- Password reset, email verification and account recovery were never built, and support does it by hand
- Two people editing the same record quietly overwrite each other
The fix
Identity gets designed before the first screen: who the actors are, what each may do, how sessions live and die, and what happens on recovery. Retrofitting roles into a system that assumed one user type is close to a rewrite of every screen.
2. The database you can no longer change
Prototype schemas get shaped by whatever the first feature needed. That is efficient right up to the moment real data is living in it.
What it looks like in production
- Adding one field takes a week because nothing was designed to be migrated
- The same fact is stored in three places and they disagree, which is the exact problem that makes AI features unreliable too
- Reports cannot be built without scanning everything, so they get slower every month
- Nobody can safely delete anything, so the data grows and the queries degrade
The fix
Decide the data model and the migration strategy up front, including how you will change it later under live traffic. This is unglamorous and it is the single highest-leverage hour in the project.
3. Payments and third-party APIs fail in ways demos never show
A demo takes one successful card payment. Production handles the other paths: declines, retries, partial refunds, disputes, currency, tax, and a customer who closes the tab mid-checkout.
What it looks like in production
- Your records and the payment processor disagree, and reconciliation becomes a monthly manual job
- A retry charges twice because the request was never made idempotent
- A supplier API changes shape or hits a rate limit, and orders silently stop being created
- An outage in someone else’s service takes your checkout down with no fallback and no alert
The fix
Model payments as a state machine with reconciliation built in, and treat every external dependency as something that will fail. Contracts, timeouts, retries with backoff, idempotency keys and alerting are the difference between an incident and an outage.
4. Security is not a phase at the end
This is where the current wave of AI-assisted building deserves a specific warning rather than a general one. The code these tools produce usually runs. Whether it is safe is a separate question, and the evidence is not reassuring.
What the testing actually shows
In Veracode’s 2026 GenAI Code Security Report (published 28 July 2026), roughly 44% of AI code generation tasks introduced a risky security vulnerability, giving an average security pass rate of 56% across the models tested. The spread by weakness type is the interesting part: SQL injection passed 83% of the time and cryptography 87%, while cross-site scripting passed 15% and log injection 12%. Veracode sells application security testing, so treat it as vendor research, but it is their own controlled testing with published per-category results rather than a survey. The pattern to take away: syntax has largely been solved, and security has not moved with it.
What it looks like in production
- Secrets and API keys committed into the repository or shipped to the browser
- Authorization checked in the interface but not on the endpoint, so anyone can call it directly
- User input rendered without escaping, which is precisely the category the models are worst at
- No logging you could use to work out what happened after an incident
The fix
A threat model on day one, secrets management from the start, authorization enforced server side, and review that assumes generated code is unvetted until proven otherwise. If you are also running agents against your systems, the same discipline applies to the ways agents get exploited in production.
5. Nobody agreed the scope, so every change is a surprise
The technical failures above are usually symptoms of one commercial failure: the work was never specified in enough detail to be estimated, so it is being discovered while it is being built.
Google’s DORA research put a useful number on the surrounding dynamic in its 2024 report: AI adoption significantly increases individual productivity and satisfaction, while negatively affecting software delivery stability and throughput. Faster typing does not fix an unclear plan. It ships the unclear plan sooner.
The blueprint: decide it before you build it
Our answer to this is deliberately unfashionable. Before we write a line of production code, we spend up to 30 days turning the idea into a complete engineering blueprint: every feature, every user flow, every integration, every technical requirement, the application architecture, the technology stack, the development roadmap, and the real scope needed to build it properly.
At the end of it you know what you are building, how it will be built, what it will cost, and what comes next. No vague estimates, and no discovering a structural problem in month four. Then senior engineers build from that blueprint using modern practices and AI assistance where it genuinely helps, covering the backend systems, integrations, security, infrastructure and testing.
We also do not disappear at launch. Every application we build carries a 180-day workmanship guarantee.
We are not the cheapest team you can hire, and not the fastest. We aim to be the team you trust when the software actually matters.
That is also why we decline projects. If we do not believe we can deliver an exceptional result, we say so before taking your money, because saying no to the wrong project is cheaper for both of us than building something we do not believe in.
Myth vs Facts
Myth: “AI can build the production version now, so this is all cheaper than it used to be.”
Fact: Generation got cheaper. Correctness and safety did not. Veracode’s July 2026 testing put roughly 44% of AI code generation tasks as introducing a risky vulnerability, and the worst categories were the everyday ones like cross-site scripting at a 15% pass rate. AI moves the cost from typing to reviewing, which only works if someone qualified is reviewing.
Myth: “Thousands of AI-built startups have already needed rescuing, so the risk is proven.”
Fact: That specific claim, usually phrased as 8,000 of 10,000 startups needing rebuilds at $50,000 to $500,000 each, circulates widely and we could not trace it to any primary research. It appears on marketing pages with no methodology, sample or fieldwork dates. We are not repeating it as evidence. The verifiable version of the argument is duller and stronger: controlled code testing shows a persistent security gap, and DORA’s 2024 report shows delivery stability falling as AI adoption rises.
Myth: “We will harden it after launch, once there is revenue.”
Fact: Identity, data model and payment state are structural. Changing them after launch means migrating live customer data and rewriting every screen that assumed the old shape. Performance tuning and copy can wait. These cannot. A vendor can force the same kind of rewrite from outside your team, which is what happened when OpenAI set a removal date for the Sora API.
Myth: “A prototype that has users is basically production.”
Fact: Users prove demand, which is genuinely the harder thing to prove. They do not prove the system can take a payment dispute, a schema change, an API outage or a penetration test. Those are different questions, and none of them are visible from the demo.
Prototype to production: assumptions versus reality
| The prototype assumed | Production reality | Where it gets decided |
|---|---|---|
| One kind of user on a happy path | Roles, sessions, recovery, concurrent edits | Identity design, before the first screen |
| The schema that suited feature one | Migrations under live traffic | Data model and migration strategy |
| One successful card payment | Declines, retries, refunds, disputes, tax | Payment state machine and reconciliation |
| External services are always up | Rate limits, outages, breaking changes | Integration contracts and failure handling |
| Security can be added later | Authorization, secrets, input handling, logs | Threat model on day one |
What this means if you are building software for a real business
If your software is going to carry real customers, real transactions and a real business, you need more than someone who can write code. You need the architecture decided, the integrations specified, the security modeled, the testing planned, and the scope agreed before the build starts.
The decision is not really build versus buy, though that framing helps for tooling, and we covered it in our build versus buy decision framework. The decision is whether the thing you are about to invest in has been engineered or merely assembled.
- Every user role written down, with what each one may and may not do
- A data model you know how to change after launch, with a migration path
- Payment and refund paths mapped, including what reconciles against what
- Every third-party dependency listed with its failure behavior and alerting
- A threat model, secrets management, and server-side authorization from day one
- Scope and cost agreed from a written specification, not from a verbal estimate
Is your prototype ready to be production?
Tick each that applies to your build.
- You cannot name every user role and its permissions
- Changing the database schema feels risky or is avoided
- Payments are not reconciled automatically against your own records
- Nobody has listed what happens when a third-party API fails
- No threat model exists, and generated code ships without security review
- Your cost estimate came from a conversation, not a written scope
If This Were Your Build, Here’s Our First Move
We would not start by choosing a framework or writing code. We would spend the first weeks turning the idea or the existing prototype into a specification precise enough to estimate: the flows, the data, the integrations, the failure paths, the security model, and the scope that follows from them. Everything expensive on this page is decided in that window.
If you have a software idea, a prototype hitting its technical limits, or an application that needs rebuilding properly, the next step is an NDA-covered strategy call to work out what you are building and whether we are the right team for it. We take a limited number of projects at a time. Tell us what you are building and we will tell you honestly what it will take.
