Prototype to production, without rebuilding the thing that already works
You have something real: users like it, the demo lands, the idea is proven. What you do not have is the boring half that lets it carry a thousand people, take payments, and survive a Monday. That half is the whole job here.
- We measure before we optimise, and show you the numbers
- Fixed price after the readiness review
- Your users should notice nothing except that it stopped breaking
Why this is worth building, and why us.
A prototype and a product are separated by work that is almost entirely invisible from the outside. Same screens, same flows, same value. The difference is what happens when two people edit the same record, when the payment webhook arrives twice, when the third-party API is down, and when someone signs up on a phone on a train.
That gap is where most promising builds stall, because it is unglamorous, hard to demo, and nobody asks about it until due diligence. It is also the only reason a working prototype does not automatically become a working business.
What the gap actually contains
- 01Auth and permissions enforced on the server, with sessions that behave on real devices
- 02A data model that survives concurrent writes, and migrations you can run without holding your breath
- 03Payments done properly: idempotent webhooks, failed-charge handling, refunds, and a paper trail
- 04Error tracking, logging, and alerts, so you hear about failures before your users tell you
- 05Rate limits, input validation, and the third-party failure paths nobody writes on the first pass
- 06Deploys that roll back, backups that restore, and a staging environment that resembles production
Priced by the distance left to cover
A prototype that needs a fortnight of hardening and one that needs its data layer replaced are different jobs, and the honest way to tell them apart is to read it. The review below does that for a fixed price and comes off whatever follows.
Three days reading the code and the infrastructure, and you get the gap list: everything standing between what you have and something that can carry real users and real money, each item costed and ordered. Credited back in full against any build you start within 30 days.
- Harden$3,4973 weeks
The build is sound and it needs the production layer around it.
- Security and access control done properly at the server
- Monitoring, error tracking, and alerting wired in
- Database indexes, query fixes, and the obvious scale cliffs removed
- Backups, migrations, and a deploy path that can roll back
- Tests on the flows that cost you money when they break
- Most chosenProduction Launch$8,9976 weeks
Going from a working prototype to something you can charge for and support.
- Everything in Harden, plus payments, plans, and the billing edge cases
- Onboarding, account management, and the flows a paying customer needs
- Performance work against real page weight and real query patterns
- A staging environment and a release process your team can run
- Load testing before launch, so the number is measured rather than hoped for
- Thirty days of support after you go live
- Scale Up$14,99710 weeks
It is live, it is growing, and the architecture is starting to argue.
- Everything in Production Launch, plus caching and background job infrastructure
- Multi-tenancy or team accounts, if the product has outgrown single users
- An infrastructure cost review, usually the fastest saving available
- An admin surface your own team can operate without a developer
- Documentation and handover aimed at the engineers you are about to hire
- We measure before we optimise, and show you the numbers
- Fixed price after the readiness review
- Your users should notice nothing except that it stopped breaking
- You own the code, the infrastructure, and the runbooks
Hardening a prototype is usually cheaper than people expect and slower than they want, because most of it is verification rather than typing. If your prototype was built on a platform you cannot export from, the honest first step is getting the code somewhere you own, and we will say so before quoting anything else.
The failures that only appear with real users
A prototype is tested by its author, who uses it correctly, one at a time, on good hardware, with a fast connection. Every assumption in that sentence breaks at launch. Two users edit the same thing. Someone refreshes during a payment. A webhook is delivered twice because the first response was slow. A phone loses signal halfway through an upload.
None of that is exotic and none of it shows up in a demo. It is the standard cost of software being used by people who are not you, and it is why the last twenty percent of the work reliably takes longer than the first eighty.
Measure, then fix, in that order
Performance work done on instinct is mostly wasted. Teams cache the wrong thing, rewrite a component that was never slow, and move to a bigger database instance to solve a missing index. It feels like progress and it changes nothing a user can perceive.
So we instrument first: real page timings, real query timings, real error rates. Then we fix in the order the data gives us. It is a less exciting way to work, and it is the reason we can tell you what actually got faster rather than assuring you it feels snappier.
When the platform itself is the ceiling
Sometimes what stands between a prototype and production is not the code but where it lives. Builder platforms are genuinely good at getting an idea in front of people, and several of them hit a wall in the same predictable place: you need a background job, a webhook you control, a query the visual editor cannot express, or simply a per-user cost that stops making sense at scale.
When that happens the move is not a panicked rewrite, it is a migration you can stop halfway. Export what exists, stand the real version up beside it, move traffic in slices, and keep the old one running until the new one has earned it. We do that work often enough that the shape of it is boring, which is exactly what you want from it.
Not claims. Shipped work.
- 01ChatberryA multi-tenant AI product taken past the demo into production, with the operational surface that requires.See the work
- 02AI Calling AgentA production system on real telephony: latency budgets, retries, and an ops dashboard.See the work
- 03Altamar ChartersA booking product running for a real business, taking real bookings.See the work
- 04Vibe coding cleanupIf it is already breaking rather than merely unready, the repair version lives here.See the work
Common questions.
01How long does it take to get a prototype production-ready?
Three weeks for hardening if the build is sound, six weeks for a full production launch with payments and onboarding, ten weeks if it is already live and the architecture has to change underneath it. The three-day readiness review tells you which of those you are looking at, for $497, before you commit to any of them.
02Can you take a Lovable, Bolt, Replit, or v0 project to production?
Yes, and it is a common starting point. The first question is whether you can get the code out, and with most of these you can. Once it is in a repository you control it becomes an ordinary hardening job. Where the platform cannot export, or the per-user pricing stops working at your scale, we migrate in reversible slices rather than doing a big-bang rewrite.
03Do we need to rebuild from scratch?
Usually not. The product decisions in your prototype are real and worth keeping. What tends to get replaced is underneath: the data layer, the auth boundary, and the deploy path. If the readiness review does say rebuild, it will say why, in terms of specific things the current structure cannot represent.
04What does production-ready actually mean here?
Concretely: access control enforced server-side, a schema with indexes and runnable migrations, payments that survive duplicate webhooks, errors that alert someone, deploys that roll back, backups that have been restored at least once as a test, and load testing that produced a number. Not a feeling, a checklist you can hold us to.
05Can you work alongside our own developers?
Yes. On a fair number of these engagements the client has one or two developers who built the prototype and have not shipped a production system before. We do the hardening with them rather than around them, and the documentation and runbooks are written so the team owns it afterwards.
Find out how far you actually are
Send us the code and tell us what launch looks like for you. Three days later you will have a costed list of everything between here and there, and it comes off the build if you go ahead.
- A real person replies, usually same day
- No sales sequence, no automated nurture
- Production Readiness Review is credited back if you go ahead