Own the Code, Not the Platform: The Real Cost of Sandbox Lock-In

The sandbox shipped an afternoon. Then the invoice did too.

Lovable, Bolt, v0, and Rork did something real. Two years ago, going from "idea on a napkin" to "running URL a teammate can click" was a Friday of plumbing. Now it's a coffee. That collapsed the cost of validating an idea by an order of magnitude and expanded the number of people who can do it by the same factor. Worth saying out loud before anything else, because the rest of this post is going to be a balance to that win, and the win is real.

The part the demo videos don't show is what happens at month seven. The prototype is a product. The team is two people now. The sandbox bill is on a credit card someone has to remember to pay, and the only way to make a non-trivial change is to keep paying the sandbox forever. The repo exists somewhere, but it isn't the source of truth — the platform is.

Here's the math behind that, and the pattern that makes the math survivable.

What the sandbox actually gives you

The contract with a sandbox is a working URL, a database, an auth provider, and a chat box that edits the whole thing on your behalf. You get velocity. You pay for it in three places at once: a monthly subscription that never depreciates, a per-seat multiplier as the team grows, and an export ceiling on what you can ever carry out the door.

The export ceiling is the part nobody reads until they're already inside.

What you can take with you

A sandbox export, on a good day, hands you:

• The rendered frontend — HTML, CSS, JS, image assets. Real, complete, deployable to any static host.
• The schema — usually a SQL dump or an ORM migration set, depending on how the platform stored it.
• The visual layer — the utility classes, the component structure, the design tokens. Most of this is in the source.

That's the good news. The good news is also most of what the demo videos are showing you.

What you cannot take with you

The things that don't make the export are also the things that made the product work:

• The agent context. Every "make the button bluer", every "fix the dashboard bug from Tuesday", every prompt refinement — that history is the sandbox's moat. The exported repo has no memory of why anything is the way it is.
• The deploy pipeline. Auth, env vars, secrets, the routing layer, the cron jobs, the email integration. Re-wiring this is usually a week of work even with the code in hand.
• The data layer's runtime behavior. The schema exports. The row-level security, the realtime subscriptions, the edge function config, the auth callbacks — those live in the platform.
• The cost controls. Outgrow the included tier and the upgrade is a price hike, not a refactor. You don't get to negotiate.
• The "extend with AI" loop. The same chat box that built the prototype is the only thing that knows the codebase well enough to edit it safely. Switch tools and the new agent has to re-learn everything from the file tree.

You can keep the artifact. You cannot keep the engine.

The monthly-forever math

Sandbox pricing in this category lands in a published range — the shape is roughly $20 to $50 per month for an individual seat, with team plans scaling by headcount and overage tiers for compute and storage. None of those numbers are exotic on their own. The exotic part is that none of them are final. The numbers below are illustrative of the structure, not quotes from a specific vendor.

# Per-seat subscription, structural shape
1 seat   × $25/month  = $300 / year
1 seat   × $25/month  = $600 over 2 years

# Team plan, same shape, multiplied
5 seats  × $40/month  = $2,400 / year
5 seats  × $40/month  = $4,800 over 2 years

# Owned alternative, illustrative
# $99 kit (one-time) + $5 VPS + $0 Postgres + standard Stripe
# ≈ $160 in year one, under $80 in year two

That math is just multiplication. The interesting math is what it's buying you at month 24 vs month 1: at month 1 it's use. At month 24 it's rent on infrastructure you could have bought outright for less.

The crossover on a single seat lands somewhere around the one-year mark. The crossover on a five-seat team lands before the first quarter ends. This isn't a knock on the sandbox — the sandbox earned the difference in month one. The question is whether the difference is still being earned in month 24, when the prototype is a product and the product has customers.

Why owning the code caps your downside

A repo you own has a worst case: a directory on your laptop, version-controlled, deployable to any cloud, editable by any agent you point at it. You can take a year off. You can switch from Claude Code to Cursor to a local model. You can change your mind about the database, the auth provider, the hosting region, the design system, the language. The repo doesn't punish any of those decisions.

A sandbox has a different worst case: a deprecation notice. The platform gets acquired, pivots, sunsets the free tier, raises prices, or — most commonly — the team's priorities shift and the platform's editor stops understanding the codebase it helped write. There is no version of this where the sandbox is the safer place to be, because the sandbox is in control of the contract.

Owning the code doesn't eliminate risk. It puts the risk on the side of the codebase, where you can read it, copy it, and reason about it. That asymmetry is the whole game.

The two-phase pattern that works

Use the sandbox. It is the cheapest way in the history of software to find out if an idea is real. Validate, ship a demo, get a customer or two, learn what the product actually has to be.

Concretely, the move looks like this:

# Phase 1: validate in the sandbox
#  - build the UI, hook up a fake auth, ship a URL
#  - charge one real customer $1 to confirm they pay
#  - cost: one subscription, one weekend

# Phase 2: move to a repo you own
git clone <sandbox-export>
#  - port auth + billing + DB to a stack you control
#  - point a real domain at a real deploy script
#  - cancel the sandbox
#  - cost: a kit + a VPS, fixed

Then, before the sandbox is the product, move the code to a repo you own. The export is most of the frontend. The schema is most of the data. The remaining work — auth, billing, deploy, the "extend with AI" wiring — is the part that compounds, and it's the part that should live in a place you control.

That's the two-phase pattern. The sandbox for velocity. The owned repo for durability. Neither is wrong. They're answers to different questions, and the trick is knowing which question you're answering at which phase.

The part that doesn't change when the platform does

The tool that's editing the code churns every six months. The model underneath it churns every quarter. The platform on top of it churns every year. The thing underneath all of that — the codebase, the conventions, the design system, the prompt set the agent extends instead of regenerates, the one-line path from git push to a live URL — that's the part that ages well.

A repo that ships with a structured design system (so a component looks and behaves the same on web, iOS, and Android from one API), a tested set of agent prompt files, and a deploy script that wires domain + DNS + TLS in a single command doesn't care which agent you point at it next. It's the substrate. The tools are the weather.

That's the only thing worth optimizing for, long-term. Buy the substrate. Rent the tool. Never confuse the two.