The Real Math Behind Buy-Once vs. Subscription for Builders

Subscriptions are a great way to ship a prototype on day one

Lovable, Bolt, and v0 collapsed the distance between an idea and a running URL. That is a real enable: in an afternoon you go from a Notion doc to a deployed app with auth, a database, and a Stripe webhook. For the first thirty days of any product — when the question is "does anyone want this" rather than "does this scale" — a metered sandbox is the fastest tool we have. I am not going to pretend otherwise.

The math starts to bend when the prototype is no longer a prototype.

The year-one math, with actual numbers

Assume you are one engineer, shipping one product, between January and December. You will pay in one of two shapes:

Subscription shape (typical sandbox)
  $25 / month × 12 months ......... $300
  plus overages on heavy weeks .... $40 - $120
  --------------------------------------
  Year-one total .................. $340 - $420

Buy-once shape (one full-stack kit)
  SaaS Dashboard kit .............. $99
  one landing page template ...... $  9
  --------------------------------------
  Year-one total .................. $108
  Year-two total .................. $  0
  Year-three total ................ $  0

The first thing to notice is that the gap on year one is not enormous. Two to three hundred dollars is real money, but for a solo founder with revenue it is not the line item that decides the company. If subscriptions bought you the thing that actually shipped the product, this would be a wash and the conversation would end here.

The second thing to notice is what happens in year two.

The compound cost is the point

A subscription is a flat line. A buy-once is a front-loaded line that goes flat after month one. Over three years:

3-year subscription cost ......... $720 - $1,260
3-year kit cost .................. $108 - $117
3-year delta ..................... $612 - $1,143

That delta buys a month of a senior engineer's time, a runway extension, or a real marketing budget. But — and this is the part nobody puts on the spreadsheet — the delta only matters if you actually ship. A kit you never integrate is more expensive than a subscription you barely use, because the kit's value is locked inside a repo you did not open, and the sandbox's value is locked inside a URL you can demo on a call.

So the honest framing is not "subs are a scam." The honest framing is: for builders who will ship and keep shipping, the curve crosses hard in year two. For builders who are still figuring out whether they will ship, the sandbox's day-rate is the right shape.

Where subscriptions genuinely win

I am giving these four their due, because pretending otherwise would be dishonest:

1. You do not write code. Drag, drop, prompt, ship. A kit is a repo. If you cannot read a repo, the kit is worthless no matter how cheap.
2. You ship three products this year. A $25/mo sub amortizes across all three. A $99 kit per product is $297, and the savings vanish.
3. You need a real SLA. Subscription vendors have support teams. An open-source kit has a GitHub issue and your own patience.
4. You are exploring, not shipping. The first 30 days of any project benefit from iteration speed. A sandbox is faster than a kit for the discovery phase, and pretending otherwise would insult anyone who has used one.

These are real. None of them is a footnote.

The hidden cost nobody puts on the spreadsheet

The number missing from both columns is the portability of your code. When you build in a sandbox, your code lives in the sandbox. You can usually export it, but the export is a snapshot — the codebase as it stood when you last clicked "download." Ongoing iteration happens against the hosted copy.

// a snapshot of your app, with:
// - auth wired to the sandbox's identity provider
// - env vars that need to be remapped to your own DB
// - a build pipeline you did not write
// - components that exist only inside the sandbox UI
// - schema migrations tied to the sandbox's hosted Postgres

The day you churn the subscription, you have a frozen artifact plus a list of things to re-wire. Some of it is mechanical; some of it is "wait, where did this component come from."

A kit starts from the opposite premise. The repo is yours on day one. You commit, you push to your own Git remote, you deploy to your own infra. If you stop using the kit vendor tomorrow, nothing changes — the code is already where your team works. The deploy script is a shell script in the repo, not a feature flag inside someone else's product.

That asymmetry compounds. A sandbox is a rental; a kit is the deed. For a year-long build, that difference is worth more than the dollar gap.

Founding-100 is itself a buy-once pitch, and here is the math

The reason "Founding-100" exists as a pricing tier is the same reason any buy-once vendor launches with a founding cohort: early buyers lock in a price that future buyers will not get. It is the same playbook as Kickstarter, as indie game pre-orders, as every Factorio-style "buy it once, own it forever" sale that ever worked. We are running a public counter, an end condition, and a published price floor because the inverse is also true: a "founding" tier without a counter, an end date, or a visible floor is just marketing. If you cannot see the math, you are not being offered math.

I am flagging this because it is the part most "buy-once" pitches hide. The honest version of the framing is: you are buying at a price that reflects the bet we are making on the early cohort, and we are betting you will tell other builders if it is good. That is the deal. It is not magic.

A decision tree you can actually use

Here is the rule I would give a friend:

Will you ship something real in the next 30 days?
├── no  → sandbox is fine; do not pay for a kit yet
└── yes
    │
    Can you read the repo you are about to inherit?
    ├── no  → sandbox until you can, then revisit
    └── yes
        │
        How many products are you shipping this year?
        ├── 1   → buy-once wins on year one, dominates after
        ├── 2   → roughly a wash; pick on taste
        └── 3+  → subscription amortizes; your call

The cell most builders actually land in is yes / yes / 1, and it is the cell where the math is most lopsided.

What this gets you

For the builder in that cell: $99 once, your code in your own repo on day one, design tokens flipping one theme across web and mobile so the same component renders identically on every platform, and a one-script deploy that takes you from git push to a custom domain with TLS. The savings against a $25/mo sandbox are real but they are not the headline. The headline is that the bill stops in month one, the code stays yours, and the people who bought in at the founding price do not get a price hike six months from now.

That is the bet. It is not the right bet for everyone. It is the right bet for the builder who already knows what they are shipping and wants the part that does not change when the model does — which is the repo, the tokens, and the deploy script they own.