How much does it cost to take an AI-built app to production?

The honest answer is "it depends" — so here's exactly what it depends on, and how to reason about the number even if you never hire anyone.

You built something real. Lovable, Cursor, Bolt, Claude Code, v0 — whichever tools you used, you shipped a working app faster than any team could have three years ago. That's genuinely impressive, and nobody should tell you otherwise. But now people are using it, or about to, and you're asking the sensible question: what does it actually cost to make this production-ready?

Nobody can quote you a real number sight unseen, and you should be suspicious of anyone who tries. What we can do is show you the levers that move the price, so you can estimate it yourself.

What actually drives the cost

Four things, roughly in order of impact:

• Size and surface area. A single-purpose tool with three screens is a different animal from a multi-tenant SaaS with billing, roles, and integrations. More surface, more to harden.
• The gap between "works" and "safe to run." AI tools optimise for something that runs. They rarely add rate limiting, input validation, audit logging, or sensible error handling unless you asked — and you probably didn't, because you were busy building the thing that matters.
• Security and data risk. This is the big one. Unsanitised inputs, secrets committed to the repo, an admin route with no auth check, a database that's readable by anyone who knows the URL. Fixing these isn't optional, and the cost scales with how much sensitive data you're holding.
• Infrastructure reality. Where it runs, how it's deployed, whether there are backups, whether a deploy can roll back, whether anyone gets paged when it falls over at 2am. Most vibe-coded apps have none of this — not because you did anything wrong, but because the tools don't prompt for it.

Notice what's not on that list: how many lines of code, or how it was built. We don't charge a penalty for using AI. Vibe-built code is just code — some of it excellent, some of it needs work, exactly like everything humans write.

Why "free assessment, then fixed price" beats the hourly meter

Here's the problem with hourly agencies: the incentives point the wrong way. Every hour of discovery, every scope surprise, every "well, while we're in here" is billable — to you. You sign up not knowing the total, and you find out as the invoices arrive. That's not malice; it's just what hourly billing does to a project with unknowns.

We do it the other way round. The production-readiness assessment is free. We go through your app properly and tell you what we find — the real risks, the quick wins, the things that can wait. Then we scope a fixed price for the productionisation work, and you approve it before we start. If the job turns out bigger than expected, that's our problem to absorb, not a surprise on your bill.

The point of a fixed price isn't that it's cheap. It's that you can decide, with the whole number in front of you, whether it's worth it — before you spend a thing.

No hourly meter. No scope creep. The unknowns get resolved during the free assessment, which is precisely when they're cheapest to resolve.

The cost everyone forgets: running it yourself

Let's say you get it production-ready. The bill doesn't stop there — it just becomes invisible, which is worse.

Because the real ongoing cost is the 2am incident. It's the Saturday a dependency breaks and you're the only one who understands the deploy. It's the security patch you didn't know you needed. It's the slow realisation that you've become an on-call engineer for your own product instead of building the next thing. That time has a price, even when no invoice shows up for it — and it's usually the most expensive line in the whole equation, paid in the currency you have least of.

Turning unpredictable risk into a predictable line item

This is what a monthly Production SLA is actually for. Not a support contract you hope never to use — a senior team that monitors the thing, patches it, responds when something breaks, and keeps it healthy while you get on with building. The unpredictable, spiky cost of "something went wrong and I have to drop everything" becomes one predictable number you can plan around. Optional, and separate from the build — you're never locked in.

So, what should you budget?

Reason about it in three buckets: the one-off cost to close the gaps (fixed, and you'll know it before committing), the infrastructure cost to actually run it (usually modest and predictable), and the cost of your own time if you choose to operate it yourself (easy to underestimate, and worth being honest about).

Get those three numbers roughly right and you can make a good decision — whether you work with us or not.

You vibed something into existence. That's the hard, creative part, and it's done. Productionising it is the boring, careful part — and it's exactly the part a senior team should carry so you can keep vibing. Build the thing. Let someone else make sure it stays up.