Every founder raising money has been told their model needs a path to profitability. So they build a spreadsheet that shows one. The spreadsheet is almost always wrong, and the more polished it is, the less I trust it.
This article is one in a series. The series discusses the method we use to judge whether a business plan is fundable. We have developed a multipart weighted scorecard, based partly on research into best practices and partly on my experience in the startup and venture space: five startups, two exits, startup investing, and founding a startup accelerator. There will be one article for each scoring category, plus one on red flags.
There's a selfish reason for doing it in the open: we are building the methodology into a managed AI agent that evaluates plans against real investor decisions, and writing each part out is how we find where it's wrong. If you're raising funding for a startup, you get the rubric we would use to grade you. If you think we have weighted something badly, tell us. That's the most useful note we can get.
This dimension is worth a little less than the market or the team, and there is a reason. Detailed unit economics at the seed stage are mostly fiction because the inputs are based on too few data points to be stable. A founder who shows me a five-year model with monthly cohorts and a 14 percent churn assumption has told me they can use a spreadsheet, not that they understand their business. So we weight the number lower than the thinking behind it, and we grade the thinking hard.
What we are checking is whether the founder knows which numbers govern their business, knows which ones they actually have, and is honest about the difference. That is a smaller, more answerable question than "will this business be profitable," and it separates founders who understand their model from those who have decorated one.
The three numbers that have to be real, and the one that's allowed to be a guess
Here is the standard I apply, and I'll flag it as the place I have hardened a vague anchor into something testable, so it is exactly where I welcome pushback.
Three numbers should be grounded in something real, even if the sample is small. 1) What it costs to deliver the product to one customer. 2) What that customer pays. And 3) what it costs to acquire them, at least roughly. A founder with ten customers can speak to all three from experience. The numbers will be noisy, and the acquisition cost will be the shakiest of the three, but they exist, and a founder who can't speak to them from real cases has not sold the thing yet, whatever the deck says.
The fourth number, the long-run lifetime value, is allowed to be a guess at the early stages, because it depends on retention over a period the company hasn't lived through. I don't penalize an honest estimate. I penalize a precise one. A founder who tells me lifetime value is "roughly three times acquisition cost, and here's the retention assumption that rests on, which we'll know in a year" is being straight with me. A founder who tells me it is 3.4 times has invented a decimal point, and the invented decimal makes me re-check everything else.
So the test is not "are the unit economics good." Early, they usually aren't, and that's expected. The test is "does the founder know which of their numbers are observed and which are assumed, and did they resist the urge to dress the assumptions up as observations."
A model that reconciles beats a model that impresses
There is a gate elsewhere in this rubric for numbers that don't reconcile, and unit economics is where that gate most often trips. The mechanism is simple. A founder builds the revenue projection top-down from a share of a big market, and the cost side bottom-up from real expenses. The two halves were never made to meet, and they don't. The revenue line implies a customer volume the acquisition budget can't possibly buy, or a price the unit economics never assumed.
The repair is not a better spreadsheet. It is to build the projection from the unit up. One customer, with its real cost to serve and real price, multiplied by a customer count the acquisition plan can defend. A model built that way is usually less exciting and always more believable, and believable is what gets funded at this stage. I would rather see a humble model I can follow than an impressive one I have to take on faith.
What changes by Series A
The forgiveness in this dimension is a pre-seed and seed allowance that expires. By the time a company is raising a Series A, it has run long enough that the numbers that were guesses should now be measured. Retention is no longer an assumption; it is a cohort chart. Acquisition cost is no longer rough; it is a figure with a trend. At that stage, the same honest "we'll know in a year" that I credited at seed becomes a flag, because the year has passed and the founder still doesn't know. The standard tightens as the evidence that should exist accumulates.
Current view, subject to change
I am confident about the reconciliation point. A model that doesn't tie together is the most reliable tell I know that nobody on the team has stress-tested their own story, and it costs nothing to catch.
The part I am genuinely unsure about is the three-real-numbers test. It is clean, which worries me, because real businesses are messier than clean tests. A hardware company, a marketplace, and a long-sales-cycle enterprise tool have very different numbers that matter, and a single rule risks penalizing a founder whose business just doesn't fit the template. As we run plans through the agent across different business types, I expect to find that the three numbers are sometimes the wrong three. When the founder who fails the test turns out to have a perfectly sound grasp of a model the test wasn't built for, the test is too rigid, and I'll loosen it. That would change my mind.
What I hold most firmly: the polish of a financial model is not evidence of anything except time spent in a spreadsheet. The honesty about which numbers are real is the actual signal, and it is the one most decks skim past.
Regards,
Charles Stack
Founder, Coworkers.Global