The real cost curve from vibe-coded MVP to production, honestly mapped

The rental web caught up to SaaS fast. Tools like Lovable and Bolt promise a working UI in minutes and a credible path to MVP without hiring a team or wiring a stack. The pitch feels honest: pay for what you use, stop when you stop.

That framing holds while the app is small. It breaks once the app is real — once users, seats, rows, storage, and background work all grow at the same time. This post walks through how that cost curve actually behaves, where the compounding comes from, and where owning your kit breaks the loop.

MVPs love meters, production hates themCopy Anchor Link

A meter is perfect for exploration. You prompt, preview, iterate, and throw away three versions before lunch. You only pay for active building time, and the hosting for a demo with ten users costs almost nothing.

Production reverses every one of those conditions. The app has to stay up, stay fast, keep history, onboard a team, remove branding, connect a real domain, run jobs on a schedule, and survive a traffic spike without a surprise bill. Each of those is a separate paid dimension on most builder platforms.

Lovable documents this directly: it now uses one credit balance for building your app, hosting it and running its built-in backend and AI features your deployed app uses, managed under Settings and Plans and credit usage. That single-balance model is convenient, and it is also the reason building, hosting, backend, and AI usage all draw from the same pool once you are live.

How the credit meter actually runsCopy Anchor Link

The Lovable credits model covers three kinds of draw in one place: build usage when you send messages to plan, generate, edit, or update your app, plus hosting and Cloud backend usage once deployed, plus AI features inside the deployed app. You track balance, usage, top-ups, and plan controls from the Plans and credit usage screen.

That matters because early teams budget only for the first bucket. They think in prompts. Production spend lives mostly in the second and third buckets: the app running, the database growing, files accumulating, edge functions firing, and end users triggering AI features around the clock.

Plan pages and credit docs change often, so treat any specific quota you read in a screenshot as stale. Check the current subscription plans and credits-and-usage docs before you commit a launch budget. The mechanism — one balance, many drains — is the durable part.

An illustrative cost scenario, labeled as math not factCopy Anchor Link

What follows is an illustrative scenario to show the shape of the curve, not a quote of current vendor prices. Prices change, plans rename, credit rates shift. Always check the live pricing and docs before you plan.

Imagine a fitness tracker that launches to about 2,000 monthly active users, with auth, a handful of screens, modest logic, image uploads for progress photos, and a nightly job that recomputes streaks and leaderboards.

// Illustrative shape-of-curve math — example only.
// Replace every number with current pricing before budgeting.
const illustrativeMonthly = {
  baseBuilderSeat: 25,      // example builder subscription
  extraSeats: 4 * 9,        // example: 4 guest trainers/coaches
  scheduledJobsAddon: 15,   // example automation add-on
  extraStorage: 10,         // example: user uploads over included quota
  extraInvocations: 10,     // example: jobs + API calls over included quota
};
const total = Object.values(illustrativeMonthly).reduce((a, b) => a + b, 0);
// total = 96 in this invented example — the point is stacking, not the sum

Start at something like twenty to forty dollars while it is just you and a prototype. Add seats for trainers, an automation add-on for scheduled streaks, storage overage for photos, and invocation overage for API and job runs. Suddenly the stack looks like ninety to one hundred and twenty dollars per month just to keep the doors open.

Annualize that illustrative range and you are at roughly one thousand to fifteen hundred dollars per year for hosting-plus-meter, before you count the time spent working around platform limits. You still do not own a portable codebase, you still cannot run the whole thing locally with real migrations, and you still cannot move infra without a rewrite or an export tax in effort.

-- What you wish you owned at month six, but cannot version on a closed builder:
-- real migrations, real seeds, real row-count freedom.
CREATE TABLE workouts (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id uuid NOT NULL REFERENCES auth.users(id),
  performed_at timestamptz NOT NULL DEFAULT now(),
  payload jsonb NOT NULL DEFAULT '{}'
);
CREATE INDEX idx_workouts_user_time ON workouts (user_id, performed_at DESC);

A single spike makes it worse. A Product Hunt mention, a creator shout-out, or a corporate pilot that imports history can multiply invocations, storage ingestion, and AI-feature calls in the same week revenue does not move. On a meter, success and cost spike together.

Why unit economics tilt against rentersCopy Anchor Link

Five compounding levers show up in almost every scale story on closed builders.

First, records and rows. Users, events, invoices, workouts — everything you want to keep is something you pay to keep. Caps force plan bumps even when traffic is flat.

Second, seats. Internal tools multiply heads: founders, coaches, support, contractors. Per-seat pricing taxes headcount, often doubling faster than revenue.

Third, execution. Every API call, webhook retry, nightly rollup, and AI completion burns meter. Background work you would run for pennies on your own Postgres and queue becomes a line item per 25k calls.

Fourth, polish taxes. Custom domains, removed branding, higher limits, audit trails, SSO — the production checklist maps almost one-to-one to higher tiers.

Fifth, exit friction. A download button is not portability. Without real migrations, seeds, environment parity, and framework-standard code, moving off means rebuilding. Teams keep paying because leaving looks more expensive than staying, which is exactly the lock-in loop.

None of this makes builders bad. It makes them rented. Rent is rational for validation and terrible for compounding assets.

What owning the kit changesCopy Anchor Link

Contrast that with buying a kit you own outright, for a one-time fee, where you pull the repo and keep it. You get framework-standard code — React and Expo on the front, Hono or Next.js on the API, Postgres underneath — plus a real design system, auth, payments, jobs, and infra as code you can change at will.

// Owned code is portable by default: standard React, typed, versioned.
export function WorkoutCard({ title, performedAt }: { title: string; performedAt: string }) {
  return (
    <article className="rounded-xl border p-4">
      <h3 className="text-base font-semibold">{title}</h3>
      <time className="text-sm opacity-70">{performedAt}</time>
    </article>
  );
}

With owned code, marginal hosting can be close to zero at this scale: a light Postgres plus a hobby web host covers the same 2,000-user tracker, and years out the marginal cost of the kit itself is still zero because you already bought it. You can swap Vercel for Fly, Supabase Postgres for Neon or RDS, Resend for Postmark, Stripe test for Stripe live — without asking permission or re-platforming.

Ownership also fixes the workflow gaps that meters cannot: local dev with real data, pull-request previews, repeatable migrations, seed scripts for demos, and background jobs you can observe and retry. If you are shipping with an AI coding agent, that agent does dramatically better on a conventional repo with readable structure and explicit rules than on a black-box builder it cannot see into.

If you are mapping that production checklist, read our ship AI MVP to production checklist alongside this cost math. Pair it with the Supabase RLS production checklist before you open rows to real users, and skim the AI app security checklist for the auth, webhook, and secrets hygiene that builders often hide from you until audit day.

When to stay on the builder versus when to ownCopy Anchor Link

Stay while the question is still whether anyone wants the thing. If you can validate in a weekend with ten users and throw it away, the meter is cheaper than any engineer, including you.

Move when three signals line up: retention exists, the schema is stabilizing, and monthly meter plus workarounds exceeds the cost of one focused rebuild week. That is usually the moment teams describe as the last twenty percent that takes eighty percent of the budget — auth swaps, Stripe edge cases, role gates, export jobs, branding removal, and the，只能 keep paying feeling.

Do the rebuild on owned code once, properly: bring migrations, seeds, auth, billing webhooks, and job runners into a repo your agent can extend. From then on every feature compounds into an asset instead of a higher bill.

Ready to stop renting the base? Browse production-ready kits your agent can actually extend at OTF templates — buy once, own the repo, deploy anywhere, and let the meter stop.

SourcesCopy Anchor Link

• Lovable Docs — Credits and usage: one credit balance for building, hosting, Cloud backend, and deployed-app AI features; Plans and credit usage screen for balance, usage, and top-ups. https://docs.lovable.dev/introduction/plans-and-credits
• Lovable Pricing and subscription plans overview: plans, tiers, and billing live here and change often — check current numbers before budgeting. https://lovable.dev/pricing