From Prototype to Production: What Changes and How

Moving a software prototype to production means replacing the parts that only work when you are the one clicking with parts that keep working when strangers use them. In practice that is five things: real authentication and data rules, payments that survive failure, tests on the behavior that matters most, a repeatable deployment, and code someone else can read. Most prototypes need all five. Very few need a full rewrite.

I'm Hanad Kubat, a senior software engineer in Vienna. I build first real versions of software for founders and owner-operated businesses, and I spend a lot of time looking at prototypes built in Lovable, Bolt, v0, Replit, Cursor, Bubble and similar tools. This guide is what I tell founders in the first call.

Key Takeaways

• A prototype proves that people want something. Production proves that the software keeps working, stays secure and can be changed by the next developer.
• Rebuild only when repair cannot reach an important requirement. Often the prototype becomes the specification and the foundation gets replaced piece by piece.
• Scope production around one core workflow that one real user can use for real work, not a longer feature list.
• Payments, logins, backups, staging and rollback are the unglamorous parts that decide whether customers trust you.
• You should own the code from the first commit, in a widely known stack, so you are never locked in.

Table of Contents

• What a prototype is, and what it is not
• Signs your prototype has hit the wall
• Repair, migrate or rebuild
• Scope the first production version around one workflow
• The production checklist
• Buy, build or both
• Freelancer, agency or fixed-price specialist
• What it costs and how long it takes
• A realistic timeline
• Perspective
• Work with me on the move to production
• FAQ
• Sources

What a prototype is, and what it is not

A prototype answers one question: does anyone want this? It can be a Figma file, a clickable demo, or a Lovable app that really runs. It is allowed to cut corners, because its job is speed.

Production answers a different question: can people rely on this? That means strangers sign up, pay, upload strange data, use it on bad connections, and come back next month expecting their data to be there. The software also has to survive you being on holiday.

The gap between the two is not about polish. It is about what happens when something goes wrong. A prototype has no answer to "what if the payment webhook arrives twice?" or "what if user A can guess the URL of user B's record?" Production code has an answer to both.

Signs your prototype has hit the wall

Founders usually come to me after one of these happened:

• The AI builder fixes one bug and breaks two others, and the project stalls at roughly 70 percent.
• Real users trigger errors that never showed up in your own testing.
• An investor, a customer's security team or a due-diligence reviewer asks questions nobody can answer.
• The platform bill has grown faster than revenue, or the platform can no longer do what the product needs.
• An agency or freelancer handed over code that nobody on your side can read.

If you recognize two or more, the question is no longer whether to move to production but how much of the prototype to keep.

Repair, migrate or rebuild

This is the decision that costs founders the most money when they get it wrong. A useful rule from one engineering write-up: rebuild only when evidence shows bounded repair or refactoring cannot meet an important requirement at acceptable risk. The signals it names are an unsafe or unsupported foundation, behavior you cannot test or release, a data model that blocks what you need, and recurring failures whose causes you cannot isolate.

Translated into plain terms:

The prototype is never wasted in a rebuild. It shows which screens users touch, which flows matter and which features nobody opened. That is the hardest part of a specification, and you already paid for it.

If you are not sure which row you are in, a short audit answers it. My Prototype Audit is a fixed €1,500, takes 3 to 5 days, and is credited against the build if you continue. You get a written verdict: keep, repair or rebuild, with reasons.

Scope the first production version around one workflow

The most common mistake in the move to production is trying to harden everything. Pick one core workflow instead.

One useful framing describes an MVP as a working system where one real user does real work and produces a measurable outcome within one iteration, not a demo. I agree with that, and it is how I scope.

To find your workflow, answer three questions:

1. What is the one thing a customer pays for or a staff member does every day?
2. What is the shortest path from sign-up to that thing being done?
3. What breaks the business if it fails: money, data, or trust?

Everything on that path gets built properly. Everything else waits. If you have not yet confirmed that people want the core workflow, do that first with a structured idea validation process. Once validated, a roadmap that ships keeps the next steps in order.

The production checklist

This is the actual work. I go through these in roughly this order.

1. Source control and environments

The code lives in a repository you own, with history. There are separate development, staging and production environments, each with its own configuration and its own database. Prototypes often point the live app at the same database you experiment on. That one change prevents a lot of disasters.

2. Authentication and access rules

Logins must do more than show a form. Each record must belong to a user or an organization, and the server must check that on every request, not just hide buttons in the interface. Test it explicitly: log in as one customer and try to read another's data. For a fuller view of what reviewers expect, see this security requirements plan.

3. Payments that survive failure

A checkout that works in test mode is not a billing system. Payment providers send events to your server, and your server must treat them carefully. With Stripe, verify the signature on each webhook so you know the event is genuine, and handle duplicates so a repeated event does not grant access twice or send two invoices. Subscription state, failed renewals and cancellations all need a defined behavior, because they are where support tickets come from.

4. Data: migrations, backups, restore

Database changes go through versioned migrations, not manual edits in a dashboard. Backups run automatically, and someone has actually restored one. A backup you have never restored is a hope, not a backup.

5. Secrets and configuration

API keys leave the code and the browser and move into the hosting platform's secret storage. If a key was ever pasted into a chat with an AI tool or committed to a repository, rotate it.

6. Tests where the consequences are

You do not need perfect coverage. One practical approach is to test the behavior with the largest consequences, for example workspace boundaries, account and subscription state, and data migrations that must preserve existing data. I write tests for the workflow that carries money or sensitive data first, then widen from there.

7. Deployment you can repeat

Deploying should be one command or one merge, not a ritual only the original builder knows. U.S. cybersecurity agency CISA's guidance on safe software deployment says changes should move through defined phases backed by robust testing, and that internal teams should use new versions before customers get them where appropriate. For a small product, that translates into automated checks, a staging environment, and a way to roll back quickly. I cover the details in a B2B SaaS deployment process guide.

8. Monitoring and a named owner

After launch, someone has to see errors before customers email you. At minimum: error tracking, uptime checks, logs you can search, and an alert that reaches a human. Then decide who handles patching, access reviews, backup tests and cost reviews. If the answer is "nobody", that is the risk.

Buy, build or both

Not every pain needs custom software. Before you commit, it helps to understand the trade-off between an all-in-one suite and best-of-breed tools for service-type businesses, especially when the release and infrastructure work needed to put your own product in front of customers is more than the problem deserves. If an off-the-shelf tool covers 90 percent of your workflow, I will say so. Custom code is for the workflow that defines your business or that no tool handles.

Freelancer, agency or fixed-price specialist

First-time founders ask this a lot. Rather than rank types of providers, check these things with whoever you consider:

• Who writes the code? The person you speak to, or someone you never meet?
• Who owns it? Ownership should be yours from the first commit, in a repository in your account.
• What is the price, and what is in it? A fixed price with a fixed scope protects you from open-ended hours.
• Can you see working progress before you pay for it?
• Can another developer take over? Ask what stack is used and whether it is widely known.
• What happens after launch? Know in advance whether support is included or separate.

These questions apply to any provider. They are also how I try to work: I build end-to-end myself, you see working progress before paying, and the stack (TypeScript, Next.js, React, Node, Cloudflare Workers, SQL, Stripe) is deliberately boring so the next developer can pick it up.

What it costs and how long it takes

My builds start from €12,000 and rescue rebuilds run €12,000 to €20,000, delivered in two to four weeks at a fixed price. Websites start from €3,500. The audit is €1,500 and is credited against the build.

These prices are possible because there is no agency overhead, no project-manager layer and no offshore markup. You pay for senior engineering time on your product and not much else. An optional continuation retainer exists for after launch, but the code is yours either way.

A realistic timeline

Here is how a typical rescue goes in two to four weeks:

1. Days 1 to 5: Audit. I read the prototype, run it, map the data and flows, and give you a keep, repair or rebuild verdict.
2. Week 2: Foundation. Repository, environments, database schema, authentication, deployment pipeline.
3. Weeks 2 to 3: The core workflow, rebuilt with tests, payments if needed, and your existing data migrated.
4. Final days: Staging review with you, production release, monitoring, and a written handover so another developer can continue.

You see working software at each step, which is how you stay in control of a project you may not be able to judge by reading code.

Perspective

Founders often assume that a prototype built with an AI tool or a no-code platform is 80 percent of a product, and that the remaining 20 percent is polish. In my experience it is closer to the reverse for the parts that matter: the visible screens are done, while the invisible parts, such as access rules, billing edge cases, backups and deployment, are still to be built.

That is not a reason to feel bad about the prototype. It did its job, and it gave you the one thing most projects lack: evidence of what users want. My view is that the right response is a small, fixed-scope step, not a large open-ended project. Audit first, decide with facts, then build one workflow properly in two to four weeks.

I keep the stack boring on purpose and hand over the code from the first commit, because the best production software is the kind you are free to move away from. If I do my job, you could hand the repository to any competent TypeScript developer tomorrow.

Hanad Kubat

Work with me on the move to production

If your prototype is running but you do not trust it with real customers, I can look at it and tell you honestly what it needs. Builds start from €12,000, rescues run €12,000 to €20,000, and the €1,500 Prototype Audit is credited against the build. You can see what I build and get in touch on my services page.

FAQ

What comes after a software prototype?

After a prototype comes validation with real users, then a decision on whether to repair, migrate or rebuild the foundation. Then you build one core workflow with real authentication, data rules and payments, test it, deploy it through a repeatable process and monitor it. Launch is the start of operations, not the end of the project.

How long does it take to go from prototype to production?

For a focused scope, two to four weeks is realistic when one person builds the whole thing end-to-end. Bigger scopes take longer, which is why I scope around one core workflow first. Additional features follow once real users are on the product.

Do I have to throw away my Lovable, Bolt or Bubble prototype?

You do not throw it away, you use it as the specification. The screens, flows and user feedback carry over. What usually gets replaced is the foundation: the database design, access rules, payments and deployment, rebuilt in maintainable code you own.

How much does it cost to make a prototype production-ready?

With me, the Prototype Audit is €1,500 and is credited against the build. Builds start from €12,000, and rescue rebuilds run €12,000 to €20,000, at a fixed price agreed upfront. The final figure depends on the scope of the workflow and the state of your data.

Sources

• When to Rebuild an MVP, IVRYN
• MVP Scoping Under Ambiguity, SuperML.org
• How to Productionize an AI-Generated SaaS App, SaaSloom
• Safe Software Deployment, CISA (October 2024)
• Manage webhook endpoints, Stripe documentation
• Suite vs Best of Breed for Small Service Firms

Recommended

• Founders: 6 Point Lovable to Production Handoff to Own the Code
• From v0 to Production: What Changes Before Real Users Arrive
• Replit to Production: What to Fix Before Real Users Arrive
• Founders' One Page Release Checklist: Staging vs Production for MVPs