The Pricing Decision You Make Before You Know What It Costs to Run
Most founders pick a price before they know the storage, compute, support, and reliability architecture it quietly commits them to. Set the number first and you can spend a year selling a plan that loses money on every account.
The most expensive number in a startup is the one you put on the pricing page before you know what the product costs to run.
This came up in a founder meeting. The team was ready to lock in prices — clean tiers, a tempting lifetime deal, the works. Then the person who actually builds the thing said the one sentence that should stop every pricing conversation cold: “I can’t tell you the price yet, because I don’t know what this will cost us to operate.”
That is not indecision. That is the correct order of operations. A price is not a marketing choice. It is the visible tip of a stack of commitments — storage, compute, support, reliability — that you make silently the moment you publish it.
You choose the number on top. The architecture underneath decides whether that number is a business or a slow leak.
A concrete version of this
Imagine you build MetricVault (a made-up product) that keeps a history of a customer’s analytics so they can spot trends. You price it at a flat monthly rate and promise to retain data “as long as you’re a customer.” It demos beautifully.
Then you do the math a power user forces on you. Retaining years of history for thousands of accounts is a storage bill that climbs every single month, forever, whether or not those users log in. The flat price never moves; the cost floor only rises.
Now imagine the other build: instead of storing everything, you query it live from the source and keep only the small, high-value results. Storage nearly disappears — but every screen load becomes a compute cost. Same product on the surface. Completely different price it can support, and completely different promises you can safely make.
You could not have picked the right price from a whiteboard. The price was hiding inside an architecture decision you had not made yet.
The order I would put pricing in
Map the cost floor first
Before any number, work out what a single account actually costs you to run: what you store, for how long, and what you recompute on every request. If you cannot state the cost of one customer, you are not pricing — you are guessing.
Identify what scales with usage
Seats are easy. The dangerous cost is the one that grows quietly with usage — records stored, pages processed, queries served. Find the meter that turns a happy power user into your most expensive account.
Name the customer-facing limits
Every limit is a cost decision in disguise: a retention window, a page cap, a scan ceiling. Decide these before launch, in plain language. An unbounded promise like “unlimited, forever” is a bill you have not read yet.
Only then choose the price and packaging
Now the number is a readout, not a wish. Once you know the floor, what scales, and where the limits sit, price and packaging fall out almost mechanically — and you can defend both.
My actual takeaway
I used to treat pricing as the fun part at the end — the number, the tiers, the lifetime deal that gets people talking. What I keep relearning is that the number is the last decision, not the first. It is a readout of choices you already made about what to store, what to run, and what to promise.
So the next time a pricing debate starts before anyone has mapped the cost floor, that is the tell. You are not pricing a product yet. You are about to commit to an infrastructure bill and calling it a price. Get the architecture right first, and the number stops being a gamble.
Get the next field note
Short, useful founder lessons on building, pricing, and the decisions that quietly commit you to a cost you have not read yet.
Related reading
Keep Reading
The Launch Problem You Cannot See Until Someone Uses Your Product
The most expensive gap in early startups is the one between what you built and what buyers think they are buying. You cannot see it from inside the building — only a real user can show you where it is.
The Enterprise Deal You Lose Before the Demo
Most small teams think enterprise deals die in procurement. They usually die earlier — when a buyer asks one question your product cannot answer yet.