How much does it cost to host a vibe-coded app?

Expect roughly 20 to 25 dollars per month per app on the platform that generated it. In August 2026 Lovable Pro is 25 dollars a month, Replit Core is 20 dollars a month billed annually or 25 monthly, and Vercel Pro is 20 dollars a month per user. That is cheap for one internal tool and stops being cheap once you multiply it by apps and by people.

Can you export the code from Lovable, Replit or Bolt?

Usually yes, and that export is the thing that decides whether anyone else can ever take the project on. Check it before you need it: confirm you can pull the full repository with its history, that the database schema and migrations come with it, and that the environment variables are documented somewhere other than the platform UI.

Is a vibe-coded app secure?

The generated code is not automatically insecure, but the platform does not give you a security posture. Secret management, access control, data isolation between customers, audit logging and GDPR obligations are yours. For a tool holding only your own notes the stakes are low. For anything holding customer or employee data they are not.

Do you have to rewrite a vibe-coded app?

Almost never. A full rewrite discards work you already paid for and pushes your next release out by months. The usual answer is to stabilise what exists, add tests on the paths where an outage costs money, then replace the weak components one at a time.

When is it worth paying someone to take over a vibe-coded app?

When the app has stopped being one person's tool. The signals are consistent: other people now depend on it, it holds data that is not yours, nobody can change it without fear, or the person who built it has moved on. Until one of those is true, keep it as it is.

The Real Cost of a Vibe-Coded App in Production

A small app built quickly, then multiplied into fainter copies as the running cost climbs

We build software for a living and we use these tools. Cursor, Claude, Lovable, Replit, Bolt: a working prototype in an afternoon is genuinely new, and pretending otherwise would be silly.

This is not a piece about how generated code is bad. It is about the bill that arrives six months later, when the thing you built for yourself has quietly become something the company depends on. Almost nobody budgets for that part, so here it is in numbers.

Contents

Building it yourself is often the right call
The subscription nobody budgets for
What changes when the whole company uses it
Hosting is not a security posture
What we actually find in generated code
You probably do not need to throw it away

Building it yourself is often the right call

If you needed a tool, described it to a model, and now you have it, that is a good outcome. You skipped a procurement cycle, a specification, an agency and a three-month wait, and you got something shaped exactly like your problem instead of something shaped like a vendor's roadmap.

For a tool that serves one person, or a team of three who all sit together, the honest advice is to leave it alone. Do not hire anyone. Do not rewrite it. It works, and the cost of making it "proper" is not worth paying for something that has one user and no consequences when it breaks.

Everything below is about what changes when that stops being true.

The subscription nobody budgets for

To keep a generated app running, you generally keep paying the platform that generated it. Verified in August 2026:

Platform	Entry paid tier	Monthly
Lovable	Pro	$25
Replit	Core	$20 billed annually, $25 monthly
Vercel (v0, Next.js hosting)	Pro	$20 per user

Two details in there matter more than the headline number.

On Lovable, a custom domain and removing the platform badge are Pro features. So the free tier is not really a way to run a business tool: the moment you want it on your own domain, you are paying.

On Vercel, the price is per user, not per app. That is the difference between a line item and a budget conversation.

And this is the floor, not the ceiling. Replit's next tier up is $95 a month billed annually, or $100 monthly. Credit-based plans add a second axis: you are buying generation capacity as well as hosting, so a month of heavy iteration costs more than a quiet one.

Twenty-five dollars a month is not a lot of money. It is, however, right at the threshold where people start asking what a subscription is for. One app, one person, nobody asks. Six apps across four teams and someone in finance asks, and the honest answer has to be better than "it was quick to build".

What changes when the whole company uses it

The platform pricing model is built around one person building one thing. Rolling the same app out to an organisation runs into the parts that were never designed for it:

Per-seat or per-app pricing that grows linearly with adoption, while the value per user usually does not.
No connection to your identity provider. No SSO, no directory sync, so joiners and leavers are managed by hand, which means in practice they are not.
Permissions that are all or nothing. Fine when everyone should see everything. Not fine the first time someone should see only their own region's numbers.
Quotas and limits that were invisible at ten users and are the whole conversation at two hundred.
No environments. There is production, and there is editing production.

None of this is a flaw in the tools. It is a mismatch between what they are for and what the app has become.

Hosting is not a security posture

Hosting gives you a URL that responds. It does not give you any of the following, and these are yours whether you have thought about them or not:

Secret management. API keys and database credentials that are not sitting in the source or pasted into a settings field.
Access control that survives someone sharing a link.
Data isolation, so one customer's rows cannot be read from another customer's session.
Audit logging, so you can answer "who changed this record" months later.
GDPR obligations: where the data lives, how long you keep it, and how you delete it when someone asks.

For an app holding your own notes, the stakes are genuinely low, and we would tell you so. For anything holding customer or employee data, this list stops being optional, and none of it appears by default because you deployed successfully.

What we actually find in generated code

The same handful of things, in nearly every audit. Not because a model writes bad code, but because these are the problems that only appear under real load, and a prototype never sees real load.

N+1 queries. The page loads a list, then queries the database once per row. Instant with twenty rows, unusable with two thousand.
Logic pasted rather than shared. The same rule implemented in four places, so fixing it means finding all four, and the fifth one you did not know about is the bug.
No tests. This is the one that matters most, because it is what makes everything else expensive. Without tests there is no way to know whether a change broke something, so every change becomes a gamble and the team stops making them.
No migrations. The schema was changed by hand in a UI, so nobody can recreate the database from scratch, and there is no path back from a bad change.
Secrets in the repository. Usually because it was faster, and usually still there.

The pattern is consistent: what the model wrote works for the case it was shown. What is missing is everything that makes the second year cheaper than the first.

You probably do not need to throw it away

The instinct when a developer looks at a generated codebase is to rewrite it. Resist that, and be suspicious of anyone who leads with it. A rewrite throws away work you already paid for, pushes your next release out by months, and reintroduces every bug you already found and fixed.

What usually works instead, in order: read the code and find out what is actually true; write tests on the paths where an outage costs money; make the database reproducible; then replace the weak parts one at a time while the app keeps running.

The first step is the one worth paying for on its own, because it is the one that tells you whether the rest is worth doing. That is what our code audit and project takeover is: a fixed-price read of what you have, ending in a report that says what is sound, what needs work, and what each fix costs. If the conclusion is that you should leave the app exactly as it is, we will write that down and you keep the report.

Before you do anything, though, check one thing: that you can export the code. Full repository, history, database schema, migrations, environment variables. Everything else on this page is a technical problem with a price attached. Not being able to get your code out is the one that has no fix.

What a Vibe-Coded App Really Costs Once It Is in Production

Building it yourself was the right call. The bill arrives later, in the subscription, the seat count, and the code nobody can change safely.