From Vibe-Coded Prototype to Production: The Real Gap

You’ve got a working prototype. It’s rough, but it moves. Your co-founder built the API in a weekend, you’re storing data in a single PostgreSQL table, and authentication is basically “if username exists, let them in.” It feels like you’re 80% done.

You’re not. You’re about 20% done, and the gap between here and production is where most founder energy, time, and capital disappears.

This isn’t about perfectionism or gold-plating. It’s about the infrastructure, security, reliability, and operational thinking that separates a demo from something customers actually depend on. Let’s walk through what that actually looks like.

The Database Problem Nobody Talks About

Your prototype probably uses one database. Maybe it’s even normalised properly. But production databases have to answer three questions your prototype never does:

• What happens when you run out of space? You need backups (point-in-time recovery), replication (failover), and monitoring that alerts you at 80% capacity, not 100%.
• What happens at 3 AM when something breaks? You need indexes on the right columns. You need query monitoring. You need to know which query is eating CPU before it tanks your entire system.
• Can you change the schema without downtime? In a prototype, you drop tables and start again. In production, you run migrations alongside live traffic. That’s a different skill.

A fintech platform we worked with discovered this the hard way. Their prototype used a single users table with JSON columns for permissions. Flexible in week 1. In production, with 50,000 active users, a single permission query was doing a full table scan every time someone logged in. The fix wasn’t adding a line of code-it was redesigning the schema, backfilling data, and deploying during a maintenance window.

This phase alone typically costs 3-8 weeks of development time and roughly AUD $15,000-$40,000 in engineering hours, depending on your data model complexity.

Authentication and Permissions Are Not “Just Security”

Your prototype probably has a login form that works. Production needs:

1. Password hashing (bcrypt, not MD5, obviously, but also salted rounds matter)
2. Session management with expiry and refresh tokens
3. Role-based or attribute-based access control (RBAC/ABAC)
4. Audit logging-who changed what, when
5. Rate limiting on login attempts
6. Proper CORS and CSRF protection
7. OAuth/SSO if you’re targeting enterprises
8. 2FA, at minimum as an option

Most of this isn’t hard. But it’s not nothing. You’re looking at 2-4 weeks here, plus ongoing thinking about permissions as your product evolves. Add a second user role, and suddenly you’re touching authentication in five different places.

Observability Is a Separate Product

Your prototype probably has console.log() scattered around. Production software needs to know, in real time, whether it’s sick.

Observability means three things:

• Logging-structured logs you can search (not just files you SSH into production to tail)
• Metrics-response times, error rates, database query counts, memory usage
• Traces-the ability to follow a single request through your entire system

You don’t need every enterprise tool. But you need something. A SaaS logging service (LogRocket, Datadog, or similar) runs about AUD $100-$500 per month depending on volume. Setting it up and instrumenting your code properly takes 2-3 weeks. Then you need dashboards. Then you need alerts that actually matter (not every error, but error rates spiking, or P95 latency crossing a threshold).

A startup we built for discovered a critical bug only when a customer complained. The bug had been happening for three days. With proper observability, they would have had an alert in the first hour. The cost of silence here is real.

Testing Changes From “Nice to Have” to “Mandatory”

Your prototype works because you’ve been using it, clicking buttons, and knowing what to expect. Production has customers who will find every weird edge case.

This means:

• Unit tests on critical logic (payment processing, permissions, data transformation)
• Integration tests on your API (does the login endpoint actually create a session?)
• End-to-end tests on core workflows (can someone sign up, buy something, and see their order history?)
• Load testing before you launch (does the system handle 100 concurrent users?)

You don’t need 100% coverage. You need coverage on the code that matters. A payment system needs more tests than a marketing page.

Building out a reasonable test suite for a typical SaaS product usually takes 4-6 weeks, spread across the development cycle. It’s not done once. It’s ongoing-every feature gets tests before it goes live.

Deployment and Rollback Aren’t Manual Processes

Your prototype lives on your laptop or a shared dev server. Production needs:

1. Automated deployment (pushing a button, not running shell scripts)
2. Multiple environments (development, staging, production) so you can test before shipping
3. Version control on your infrastructure (your database config should be in Git, not a secret note)
4. The ability to rollback in minutes if something goes wrong
5. Zero-downtime deployments (your customers don’t want to see “service maintenance” at 10 AM on a Tuesday)

Most modern teams use Docker, Kubernetes, or managed platforms (AWS ECS, Render, Railway, Fly.io). Setting this up isn’t one week. It’s understanding your options, choosing one that matches your team’s skill level and your product’s scale, and then learning it properly. Rough estimate: 3-5 weeks to get this stable.

The Real Timeline

Here’s what a real progression looks like for a SaaS product going from prototype to production:

• Weeks 1-2: Database design for scale, migration strategy
• Weeks 3-4: Authentication, permissions, audit logging
• Weeks 5-6: Observability (logging, metrics, alerting)
• Weeks 7-9: Testing infrastructure, test coverage on core flows
• Weeks 10-12: Deployment pipeline, staging environment, runbooks
• Weeks 13-16: Security review (SSL, API rate limiting, input validation, secrets management)
• Weeks 17-20: Performance optimisation, caching strategies, database query optimisation
• Weeks 21-24: Documentation, monitoring dashboards, on-call runbooks

Some of this runs in parallel. Some depends on others. The point: it’s a real 5-6 month effort for a product that doesn’t have crazy infrastructure needs. If you’re processing payments, handling compliance, or managing user-generated data at scale, add more time.

This is why founders often feel shocked. Your prototype felt fast because you weren’t thinking about any of this. Production software is slow because every line of code has to answer questions the prototype never had to.

What Actually Moves the Needle

If you’re at the prototype stage and thinking about going to production, focus on these three things:

• Is your core business logic sound? Don’t spend six months building infrastructure for a product idea that doesn’t work. Validate the idea with real users first, even if it’s rough.
• Who maintains this? If it’s one person, design for simplicity. If it’s a team, you can afford more sophistication.
• What are your actual scale needs? Planning for 1 million users from day one is waste. Plan for 10,000, then architect upgrade paths.

If you’re ready to move from vibe-coded prototype to actual production software, the real work starts now. It’s not glamorous. It’s not something you build in a sprint. But it’s the difference between something you use and something your customers rely on.

If you’re in this phase-prototype works, market signal is real, now what-talk to Amora about your build. We move fast on the stuff that matters and don’t waste time on the stuff that doesn’t.