From Vibe-Coded Prototype to Production: The Real Gap

You’ve got a prototype that works. Your co-founder built it in two weeks. Your investors saw it running, and it impressed them. Your first customers are asking when they can use it.

Then you ask your developer: “How long until production?” And the answer is never the number you expected.

The gap between a prototype and production-grade software is where most founders hit reality. It’s not about the feature set-it’s about everything underneath that doesn’t show up in a demo.

Why a Prototype and Production Are Different Animals

A prototype proves a concept. You’re testing whether the core idea works, whether users understand it, whether they’ll pay for it. Speed is everything. A single database, hardcoded values, no error handling, scripts running on a personal machine-that’s fine. The prototype has one job: validate the assumption.

Production is different. Production runs on someone else’s machine, at scale, with real data, under variable load, at 3 AM on a Sunday when things break. Production needs:

• Proper database architecture (scaling, backups, replication)
• Authentication and authorisation that actually protects user data
• Error handling that doesn’t leave your users staring at a 500 error
• Monitoring so you know when something’s broken before your customers tell you
• Data validation at every layer, not just the frontend
• Security hardening against the attacks people will actually run
• Deployment pipelines so you’re not SSH-ing into a server at midnight to fix things

That’s not optional. That’s the difference between a demo and a business.

The Cost Is Mostly Not Code

Here’s what surprises founders: the biggest time sink in moving from prototype to production isn’t usually writing new features. It’s infrastructure, testing, and architecture work that nobody sees.

A fintech product we worked with had a prototype that processed transactions. It worked. But production required:

1. Audit logging (every transaction, every state change, immutable records)
2. Reconciliation logic (because eventually, the data won’t match reality)
3. Rate limiting and fraud detection (before customers exploit it)
4. Compliance documentation (to prove the system works as claimed)
5. Rollback procedures (because deploys will go wrong)

The prototype code? Maybe 30% of the final codebase. The rest is plumbing. And plumbing is tedious.

Time-wise, a rough breakdown: you might spend 40-60% of production engineering effort on infrastructure, testing, and operational work. Only 40-60% on new features or refactoring the prototype code. And that assumes you’re not starting from legacy decisions that need unwinding.

Database Architecture Is Where Prototypes Break

The prototype probably uses a single database. Good. That’s fine for validating the model. But when real load hits, single databases reveal their limits fast.

In production, you need to think about:

• Read replicas (so reporting queries don’t lock up your transactional database)
• Backup and recovery (you will lose data. The question is how long it takes to get it back)
• Connection pooling (databases have a connection limit; your app will exhaust it without pooling)
• Migration strategy (you’ll need to change the schema; it needs to happen without downtime)
• Query performance (a query that takes 2 seconds on 1,000 rows takes 45 seconds on 10 million rows)

And if you’re using an AI component-which most new products are now-add vector databases, embeddings storage, and query optimisation on top. That’s another tier of infrastructure that doesn’t exist in the prototype.

The jump from “local SQLite file” to “production PostgreSQL with replicas and monitoring” is roughly 3-4 weeks of solid engineering work, minimum.

Testing Moves From “I Clicked It” to Automated

The prototype was tested by your team clicking around. That works until it doesn’t. The first time a customer hits an edge case you didn’t think of, you learn the hard way that “works on my machine” isn’t good enough.

Production needs:

• Unit tests (does this function do what it should?)
• Integration tests (do the parts work together?)
• End-to-end tests (can a real user complete a real workflow?)
• Load tests (does it break under expected volume?)
• Security tests (can an attacker do something they shouldn’t?)

Writing good tests isn’t fast. A rule of thumb: for every 1 line of production code, you might write 1-2 lines of test code. That’s not overhead-that’s investment. It saves you from shipping bugs and waking up at 2 AM.

A typical cycle: write test suite, hit 60-70% coverage, optimise the obvious slow paths, add security tests, run against staging. Total: 2-3 weeks for a basic SaaS product.

Deployment and Operations Are Hidden Costs

The prototype runs on someone’s laptop or a free tier cloud account. Deploying it means copying files around or clicking a button in a dashboard.

Production needs a deployment pipeline. You need to be able to push code safely-rolling back if things break, without taking the system down. You need monitoring so you know when it’s broken. You need logs so you can debug it after it breaks.

Setting that up properly takes time:

• CI/CD pipeline (automatically test and deploy on push)
• Infrastructure-as-code (your servers and databases are defined in version control, not configured by hand)
• Monitoring and alerting (you get a Slack message when things go wrong, not a customer email)
• Logging that’s actually searchable (not just a file on a server)

If you’re outsourcing this to a managed platform (AWS, Vercel, etc.), you’re saving setup time but not thinking time. You still need to understand what’s happening. If something breaks at 3 AM, you need to know how to fix it.

Rough timeline: 1-2 weeks to get a solid ops foundation in place.

Real Numbers on the Time Gap

Here’s what we typically see:

• Prototype to MVP (working prototype + basic ops): 3-5 weeks
• MVP to production-ready (add testing, monitoring, security hardening): another 4-6 weeks
• Production-ready to genuinely stable (edge cases found and fixed, performance tuned): another 2-3 months of real-world use

If you’ve got a working prototype today, you’re probably 8-12 weeks away from something you’d honestly call production. Not 2 weeks. Not 4 weeks. Eight to twelve.

That’s assuming you’ve got a good developer who knows what they’re doing. If you’re learning as you go, double it.

The Founder’s Choice

You’ve got three realistic paths:

1. Do it yourself, slowly. You’ll learn a lot. You’ll also spend 3-4 months building plumbing instead of talking to customers.
2. Hire someone to build it properly. More expensive upfront. Faster. Fewer things will break in production.
3. Work with a team that builds for speed and quality. We ship MVPs live in 28 days because we’ve already solved the infrastructure, testing, and deployment problems. You don’t pay for us to figure out how to do DevOps-we already know.

If you’re serious about getting to market-about moving from validated idea to actual business-the gap between prototype and production is real. Plan for it. Budget for it. Don’t pretend your demo is a product.

If you want to talk through what production actually looks like for your specific idea, talk to Amora about your build. We can give you real numbers on what you’re looking at.