End the Meter: Why Owning Your Code Beats the Subscription Credit Spiral

Lovable just made it cheap to discover what an app should be. v0 typed a dashboard into existence in the time it took to think about a dashboard. Bolt scaffolded a SaaS shell while the README was still warm. The minutes-to-working-prototype barrier fell off a cliff somewhere in 2024 and it hasn't come back.

Use these. They earned their spot on the shelf. The thing I want to put under the microscope today is what happens when the demo turns into a real product and the meter is no longer rounding to zero.

The shape of the new loop

A prompt, a stream of tokens, a UI render. Click "fix this", another stream, another cost. That's the loop, and for a weekend prototype, it is genuinely the fastest way to find out if an idea is worth building.

A practical way to think about it:

# describe the app in one sentence, get a running prototype
lovable new "SaaS dashboard with team-scoped charts and Stripe billing"

# the loop, repeated forever
chat → "add this field"
chat → "wire the form to /api/save"
chat → "dark mode on the sidebar only"

For the first hour this feels free. The first twenty prompts feel like free. Then copy starts getting tweaked, corner radii adjusted, dropdowns darkened, date pickers added — and the credits become a line item you'd rather not see on the dashboard.

This isn't a complaint about the tools. They are honest about the meter, and the meter pays for the inference that makes the loop tight. What's worth mapping out is what the meter looks like at week six, not at hour one.

Why the curve gets steeper as the app grows

The naive mental model is "more code = more tokens = more cost." That's true. The part that surprises people is that it's worse than linear. Three things compound as the app gets serious:

1. Longer context per prompt. The model has to re-read more files per request. A new screen on a small app fits in just a few thousand tokens of context. The same screen on a sixty-file project can swell by an order of magnitude, because the assistant has to thread in conventions, route checks, and existing form state on every response.
2. More corrections per feature. A small app regenerates from scratch and that's fine. A more developed app needs targeted edits — add a field, wire a hook, update a type — and each one is a fresh prompt carrying fresh context.
3. More rollback work. Most sandboxes are linear rather than tree-based. Get a feature wrong and you spend credits re-prompting back to a known-good state. There is no free git diff.

So the same feature costs more on month three than it did on day one. Not because the tool is gouging. Because the prompt has to carry more of the project on every turn.

Sketch the math

I'm not going to invent specific multipliers — the shape is what matters:

• Week one: a handful of hours of iteration, a few dozen prompts, the meter is rounding noise.
• Week four: a real MVP exists, the prompt count climbs, the meter is a line item worth noticing.
• Week twelve: shipping-mode work, every tweak costs, every rollback costs, and a subscription and a credit burn live in the same dashboard.

Two paid meters stacked on top of each other is the bit that doesn't show up in the launch demo. The tool's subscription gets you in the door; the credits pay for the inference that makes the iteration fast. Together they form a curve that bends up just as the app starts to matter.

[[COMPARE: subscription + credits curve vs flat ownership]]

The vertical axis is cost per quarter; the horizontal is weeks of work. Subscription-plus-credits looks like a slow hill that never tops out. Flat ownership stays at one number for the life of the project.

The moment you graduate

There's a single decision that turns a sandbox project into a product: where the canonical repo lives. Most teams delay it.

A useful rule of thumb: when the first user (even if it's you) needs to keep using it for two more weeks, it's a product. When it's a product, it's not a sandbox anymore. Data models harden. Auth tightens. Redirect URLs stabilize. Copy stops being rewritten by the model every Friday.

At that moment, do three things:

1. Export the codebase. Most sandboxes have an export — git, zip, or "transfer to repo." Use it. Don't wait for "done"; done is a myth.
2. Pick the canonical tree. The sandbox becomes a sketchpad. The owned repo becomes the truth. Drift between two copies of the same app is more expensive than credits.
3. Replace the parts the sandbox can't do well. Auth providers, payment flows, push notifications, build pipelines — these have first-party SDKs you can drop into the owned repo without the sandbox knowing about them.

That last point is where the meter ends.

How to use the sandbox without it owning the codebase

Concrete habits that kept the meter honest on the last product I shipped:

1. Timebox the sandbox. First three days, all sandbox. After that, every meaningful change goes to the owned repo. The sandbox stays only for "what should this look like" questions.
2. Export early. Don't wait for a clean export. A half-finished export is fine; a finished app you cannot extract is not.
3. Set a credit ceiling. Most sandboxes have a hard-limit toggle in their settings; turn it on. Deciding your weekly spend in advance is the difference between a creative constraint and a meter shock.
4. Move heavy edits local. Once architecture settles, anything multi-file — schema changes, type rewrites, route splits — is cheaper in your IDE than in a fresh prompt.
5. Switch models deliberately. A prompt that took a chunk of credits on one model might take a tenth on another. But switching mid-project is its own cost. Move on purpose, not because the meter nudged you.
6. Keep one source of truth. Two copies of the same app — sandbox and tree — will drift. Pick the canonical tree on the day the project commits to being a product.

None of this is anti-sandbox. The sandbox is the best prototyping tool ever shipped. The point is to remember that prototyping is the smallest part of building a product.

What changes when you own the repo

A project that's yours:

• Lives in a git repo you control.
• Builds and runs from a single npm install.
• Edits in any IDE, with any model, with no credits meter.
• Refactors in seconds because the model can see the whole tree.
• Ships to production with one deploy script — domain, DNS, TLS, mobile build — no per-deploy credit.

The sandbox is the right tool for finding out what to build. The owned repo is the right tool for building it. The mistake is staying in the sandbox past the point where the answers are known.

How OTF slots in

This is where OTF earns a sentence.

A single install gives you a UI layer of ~200 components where the same Button, the same Card, the same Form render on web, iOS, and Android. Same name, same props, same look, one API.

# pull the UI layer into your owned repo
npm install @otfdashkit/ui @otfdashkit/ui-native @otfdashkit/tokens

import { Button } from "@otfdashkit/ui";          // web
import { Button } from "@otfdashkit/ui-native";  // iOS / Android

// both:
<Button variant="primary" onPress={submit}>Save</Button>

Design tokens flip one theme across web and mobile so a button on iOS is the same button on the web app at the same moment — no per-platform prompt to keep them in sync. You can take that base and edit it locally, commit it to your own repo, and stop paying per prompt the moment you stop asking the sandbox to add a file.

The shipped kits come with CLAUDE.md, .cursorrules, and twenty-plus tested prompt files, so a coding agent — Claude, Cursor, anything that reads the file tree — extends the repo instead of regenerating it. Same model, same convention, no token meter between the answer and the diff. A twenty-four-item design checklist runs as a script before any kit ships, and the deploy script wires domain + DNS + TLS + a mobile build in one go — no per-build credit, no sandbox to debug through.

For the parts that ship as a full product — auth, billing, DB, Stripe wiring, mobile build pipeline — the paid kits hand you those modules as a starting repo, not a token budget. You pay once ($99 per kit, $149 for the bundle), the code is yours, and there's no dashboard telling you the cost of next Tuesday's auth refactor.

That's the durable layer underneath the model churn. The model changes; the code you wrote and the repo you own don't.

Closing

The fastest way to find out what to build is still a sandbox with a credit meter. The cheapest way to keep building it is the repo you own. OTF is the second half of that sentence — a UI layer and a set of full-stack kits that you pay for once, then edit free in any IDE forever.

Use the sandbox for the discovery. Use OTF for the kept part. The meter ends.