Adding AI to a bootstrapped SaaS: do the free-tier math first

Every AI feature proposal on a bootstrapped product should start with the same unglamorous step: compute the cost per unit of work before writing any code. Not “AI is cheap now” — a number, for your feature, on your volume.

Here’s what that looked like when we scoped AI-drafted visit notes for ChiroSimple, a self-funded EHR where the infrastructure philosophy is “free tier first, paid only when the feature has proven itself.”

Step one: define the unit

The unit of work was one drafted visit note: the model gets the appointment context and produces a structured draft the practitioner edits and signs. Measured against a realistic prompt, that came out to roughly 3,000 input tokens and 800 output tokens per note.

That’s the number everything else hangs off. Without it, provider pricing pages are noise.

Step two: price the unit across providers

With a unit defined, each provider’s free tier converts into a concrete daily capacity:

Two things in that table drove the actual decisions.

The model-size lever is enormous. Same budget, same feature: ~66 notes/day on a 120B-parameter model versus ~450/day on a 1B model. That’s not an optimization detail — it’s a product question. If the small model’s drafts are 80% as good and the practitioner edits them anyway, the small model carries you 7x further on the same free allowance.

Read the fine print on scope. Workers AI’s 10,000 free Neurons per day are per account, not per project. If three products share the account, they share the allowance. The kind of detail that never makes it into the launch blog post and absolutely makes it into your incident channel.

Step three: decide what the free tier is for

The free-tier capacity — call it 66 notes a day fleet-wide on the better model — sounds small. For a launch, it isn’t. It’s enough to put the feature in front of every active clinic, watch whether drafts actually get used, and learn what the real per-clinic volume is, all at $0 marginal cost.

That’s the correct role of free tiers on a bootstrapped product: launch runway, not architecture. The design rules that follow from taking that seriously:

Build the fallback before you need it. Free tiers shrink, rotate models, and add rate limits without asking. The feature has to degrade gracefully: queue the request, fall back to a paid provider behind the same interface, or — for anything search-shaped — fall back to non-AI behavior entirely. (This is also why our retrieval features are built lexical-first: embeddings are an optional enhancement, off by default, so the product is fully useful when the AI budget is zero.)

Meter from day one. If you don’t record tokens-per-request and requests-per-clinic from the first deploy, you’ll be negotiating your first paid-tier bill with no data about which customers or features drive it.

Let the unit cost gate the roadmap. Once you know a note costs a fraction of a cent on a small model, “AI-draft every note automatically” and “AI-draft on demand” become comparable line items instead of vibes. Some features die at this step — correctly. If the unit math only works on a model too weak to do the job, the feature isn’t ready, and it’s far cheaper to learn that from arithmetic than from churn.

The general rule

Bootstrapped AI features fail in two boring ways: costs that scale faster than revenue, or quality too low to matter at a price that’s affordable. Both failure modes are visible in advance through the same three-line calculation — tokens per unit, price per token, units per day of budget.

Venture-funded products can skip the arithmetic and eat the burn while they find out. Self-funded ones don’t get that option — which, honestly, is an advantage. The discipline of pricing the unit first means every AI feature that ships already has a business case, a fallback, and a meter. That’s more than most funded products can say about theirs.