Three weeks after launch, a founder opens the billing dashboard for the first time since the app went live. The number is not what they remember agreeing to. They never agreed to a number at all, because nobody set one. The AI features were switched on by default, the database was provisioned by default, and the bill grew the same way.
"Nobody said it would cost this much to run," they tell a co-founder.
"Nobody chose it," the co-founder says. "The defaults did."
The scene above is a composite of conversations we have had with several founders. The pattern is not: the build was cheap, sometimes close to free, and the running cost showed up later, bigger than anyone modeled, owned by no one.
The Real Problem: The Build Bill and the Run Bill Are Different Bills
Founders track what they spent building the product. It is a small number, it happened once, and it is easy to remember. What they do not track is what the product costs every month to keep running, because that bill arrives in three separate places, none of which looked like a decision at the time.
The build cost is a receipt. The run cost is a habit nobody formed. That gap is where the surprise lives, and it grows every month you do not look at it.
The Three Bills Nobody Signs Up For
Platform credits that outlast the build. Many AI coding tools bill in credits or seats that keep renewing after the build sprint ends, because the team keeps using the same tool for small fixes. This cost is at least visible on a card statement. It is rarely the biggest bill.
Per-request AI calls baked into the product itself. This is the one founders miss. If your product calls an AI model every time a user summarizes a document or searches with natural language, that call has a cost, and it repeats for every user, every time. Say a feature costs $0.01 per call, and an active user triggers it 30 times a month. At 300 users, that is 0.01 times 30 times 300, or $90 a month, for one feature. Add a second feature that calls a model on every page load instead of once a session, and the number doubles or triples without anyone changing a price.
Fix: for every feature that calls an AI model at runtime, write down the cost per call and the expected calls per user per month before you ship it, not after the invoice arrives.
Infrastructure provisioned by default, not by decision. A hosted database, file storage, and background functions all ship with a starting tier chosen by whoever set up the project first, usually under time pressure. Storage that auto-scales, connections that never get pooled, and functions that run on every request instead of on a schedule are common defaults. None are wrong on day one. All are worth a decision once you have real users, a discipline close to the automation audit we run for manual processes: find the recurring cost, name an owner, fix it once.
Check: list every service your product provisions automatically and write next to each one whether a person chose the tier or the platform did.
How the Math Actually Scales
The dangerous part is not the size of any one bill. It is which of the three bills above scales per user and which scales per request, because those compound differently.
Take a single AI feature: a per-request cost of $0.02, and an assumption of 20 requests per active user per month. At 50 users, that is 0.02 times 20 times 50, or $20 a month. Nobody notices. At 300 users, the same math gives $120 a month, still easy to miss inside a larger cloud bill. At 2,000 users, the same feature, same price, same usage pattern, costs 0.02 times 20 times 2,000, or $800 a month, for a single button nobody re-evaluated since launch.
Now change one assumption: usage per user rises from 20 requests a month to 60, because that is what a successful feature does. At 2,000 users, the same feature costs 0.02 times 60 times 2,000, or $2,400 a month. The per-unit price never moved. The bill tripled because engagement is exactly what you were trying to build, and nobody modeled what engagement costs.
This is the shape every recurring AI cost takes: flat and invisible at low volume, then suddenly the largest line on the invoice once the product works. It belongs in the same room as "how much does an MVP actually cost": build cost and run cost are one budget, not two.
The One-Page Cost Model You Can Copy Into a Spreadsheet
You do not need a finance team to model this. You need one sheet with these columns, filled in for every AI feature and infrastructure service:
| Column | What goes in it |
|---|---|
| Cost driver | The specific feature or service (e.g. "document summary," "hosted database," "file storage") |
| Unit | What you are charged per (per request, per gigabyte, per seat, per hour) |
| Cost per unit | The price per unit, stated as an assumption if you do not have exact pricing yet |
| Units per active user per month | Your estimate of usage, from real data once you have it, from a guess before you do |
| Active users | Your current count, and a second row for a projected count |
| Monthly total | Cost per unit times units per user times active users |
| Owner | The one person who reviews this line every month |
| Review cadence | How often the assumption gets checked against real usage |
Fill this in before you ship a feature that calls a model, not after. Writing "units per active user per month: unknown" is usually the moment a team realizes they never measured it.
Five Defaults to Change This Week
- Cap AI calls per user per session. A hard ceiling costs nothing in a normal session and stops one runaway loop from becoming a five-figure surprise.
- Cache anything that does not need to be regenerated. If ten users ask a near-identical question, pay for that AI call once, not ten times.
- Move background jobs off request-triggered functions and onto a schedule. A nightly or hourly job usually does the same work as a function firing on every page load, for a fraction of the cost.
- Set a billing alert at a number that would make you uncomfortable, not the number the platform suggests. Defaults are conservative for the platform's benefit, not yours.
- Right-size the database and storage tier to your actual data, not the starter tier's ceiling. Most seed-stage products pay for headroom they will not need for a year.
The Playbook We Use
When cost review is part of a Fractional CTO engagement, it looks the same every time: we pull the last three months of every bill tied to the product, not just the largest one, because the second and third largest bills are usually the ones nobody has checked since launch. We build the one-page model above with real numbers for every AI feature and every infrastructure service, then assign an owner and a monthly cadence, the same discipline behind spending the first $50,000 on product, not infrastructure mistakes.
This usually takes a day, not a quarter. Most of the recovered cost comes from two or three defaults that were never decisions in the first place.
The Counterintuitive Part
Founders assume the cheapest way to build is the fastest way, and worry a senior review of architecture and cost will slow them down. In practice, the products with the lowest run cost are usually the most boring ones: a cached response instead of a fresh model call, a scheduled job instead of a function on every request, a database tier chosen on purpose instead of by default. Boring is slower to demo and cheaper to run, the opposite of what most AI coding tools optimize for by default. The senior review that catches this is not about correctness alone. It is about asking what a feature costs at ten times the users before you ship it, a question no AI coding tool asks itself.
What to Do Tomorrow
- Pull your last two months of bills for every service tied to the product and total them, not just the one you remember signing up for.
- Build the one-page cost model above for your three highest-usage AI features, using real numbers where you have them and stated assumptions where you do not.
- Assign one person to own the monthly review, with a standing 30-minute slot on the calendar.
Frequently Asked Questions
Why did my AI-built app get so much more expensive after launch? Most of the cost was never a decision. Tools default to generous infrastructure tiers, and AI features often call a model on every request instead of a cached one. Usage that felt free with a handful of test users compounds fast once real users arrive, because the cost scales with requests, not with team size.
How do I estimate what an AI feature will cost before I build it? Multiply the cost per model call by the calls you expect an active user to trigger per month, then multiply by your target user count. Do this for every feature that calls a model at runtime, before you ship it, using conservative assumptions you write down and check later.
Is a high cloud bill a sign we built the product wrong? Not by itself. A founder who can point to the exact features and services driving cost, and who reviews that number monthly, is in a strong position even if the total is high. A bill with no model behind the number, owned by no one, is the real problem.
Who should own the monthly cost review at a five-person startup? Someone technical, because the fix usually means changing how a feature is built, not just downgrading a plan. If nobody on the team has the time or background for it, a fractional advisor reviewing the bill monthly is cheaper than the surprise it prevents.
If your monthly bill does not match what you think you built, book a diagnostic call and we will walk through the cost model with you. This kind of review is part of our Fractional CTO & Technical Advisory service.