Forecast a Pre-Revenue Company Without Inventing a Sales History

You can draw a revenue curve for a company that has never charged anyone. Nothing about the drawing itself is dishonest. What makes it a problem is that a curve is an argument about evidence. A smooth line from month one to month twenty-four borrows the visual grammar of a chart built from last year's invoices, and a reader looking at the two side by side has no way to tell which one they're seeing unless you tell them.

The deck this article works against does something more specific than optimism. It takes interview notes — conversations in which people described a problem and said they might pay for a solution — and turns them into projected subscriptions. Month one of the projection equals the number of people who were interviewed. Then it climbs.

Two things are wrong there, and only one of them is arithmetic. The arithmetic fails because a conversation isn't a payment and a sentence isn't a rate. The deeper failure is that the chart has borrowed a history the company doesn't have. It reads as though someone observed something.

The fix isn't to delete the forward-looking page. A pre-revenue company genuinely owes its reader a view of the future; that's most of what the conversation is about. The fix is to stop producing one document where two are needed: a conditional commercial model that says what would have to be true, and a milestone-and-resource account that says what the money buys and what it will teach you. They answer different questions, and both belong in the room.

The company used below is invented for this article. No real pre-revenue deck, founder account, or interview record was examined in writing it, and nothing described here was built, tested, or observed. Treat the specifics as stipulated rather than reported.

State what exists without turning it into sales evidence

A pre-revenue company usually has more than nothing and less than a sales history, and the first job of the deck is to say which of those things it has, in the language each one has earned.

A working prototype supports a claim about product state, and only as of a date. A clinician can create an appointment slot; a patient can request one. That sentence is defensible. It says nothing about whether anyone wants to use the thing, and it says nothing at all about price.

Interview notes support claims about what people said in a conversation. That is a real fact, and a valuable one. It becomes a falsehood at the moment it's converted into a proportion. Eleven people saying "I'd probably use that" is a record of eleven sentences. It isn't an estimate of an addressable market, and it isn't a conversion rate with a small sample size.

Reported intent sits one rung up. Someone said they would consider a paid pilot. Still a report of speech, but the speech is closer to a decision — closer enough that it deserves its own line rather than being folded into "customer interest."

A signed agreement records that an organization agreed to do a defined thing, often for free, often with conditions. It's evidence of willingness to participate in an activity. If the agreement specifies a price and the price is later invoiced and paid, you've crossed into something new.

A paid invoice is the first item on the list that says anything about willingness to pay, and even it is one observation at one price under one set of circumstances.

Put those in order and a reader can see the ladder. Collapse them into a single bar labeled "traction" and the ladder disappears, which is usually the point of collapsing them.

Then name the absence. As of September, no one has paid for this product. That sentence is stronger than the alternatives, not weaker, because it's the only one on the slide the reader can't catch you at. A chart that starts at zero and rises smoothly is a way of saying the same thing while implying you know the slope.

Date the claims, too. A prototype's capability is a claim about the day you tested it. Interview notes carry a date and a set of questions; if the questions changed halfway through, that's worth saying, because two sets of answers to two different questions aren't one dataset.

Build a conditional commercial model where every proposition is either defined or named as open

Five things have to be accounted for before a revenue model is conditional rather than decorative, and each of them can be handled in one of two ways: settled, or left visibly open.

The customer, specifically enough to be found and counted. The offer — what is being sold, and what it replaces or sits alongside. The unit the price attaches to — seat, clinic, site, transaction. The event that counts as a paying customer — signature, first invoice, first invoice paid. The timing, which is driven by who does the onboarding and how many they can do.

A model is conditional when it says which of the five it has fixed and which it hasn't, and makes clear which open questions the rest of the deck is designed to test and which it leaves for later. A model is decorative when it settles all five without saying so. A curve with a specific average revenue per account has already made the pricing decision in private, and presenting it as a scenario conceals a choice the team still has to make and defend.

With those five accounted for, the arithmetic is almost trivial:

R(t) = A(t) × a × c × p

where A(t) is the number of accounts that have taken a defined first step by month t, a is the share of those that reach activation, c is the share of activated accounts that become paying, and p is the monthly price. Across several cohorts, month-t revenue is the sum of every earlier cohort multiplied by a, c, p, and a survival factor — a company that started ten accounts in month three earns from those accounts in month twelve only to the extent they're still there.

The expression multiplies, which is the whole point. Halve any input and the output halves; set a to a placeholder and the total becomes a function of a placeholder. So the model's value is not the total. Its value is the dependency structure: it shows which input the business is most exposed to, and it makes obvious that a number without a is a number about a.

Almost everything in that formula is unmeasured for a pre-revenue company, so each rate gets a label. Assumed. Stipulated. Untested. Being tested by the pilot on the next page. The failure mode isn't using an assumption; it's letting an assumption and an observation sit in the same table without distinguishing them, so that the reader supplies the credibility from the observed column to the invented one.

One input behaves differently, and it's worth building on. A(t) isn't free. It's capped by how many accounts the current team can onboard in a month — a checkable statement about staffing rather than a guess about demand. If the projection requires fifty accounts by month six, it also requires a hire. That dependency is worth surfacing even when every rate around it is a placeholder, because it's one of the few things in a pre-revenue model you can actually verify.

The invented case. Relay is a fictional company selling scheduling software to independent physical therapy clinics: a working prototype, a stack of interview notes, no paid customers. Its draft deck plots the conversations as subscribers. A defensible replacement page looks like this.

What would have to be true

Customer. Independent physical therapy clinics, single location, two to six clinicians, in one metro area.

Offer. Relay's scheduling module. Unresolved: whether it replaces the clinic's existing scheduling tool or runs alongside it. Unresolved: whether the price attaches to the clinic or to each clinician.

Paying customer. The clinic's first invoice, paid.

Activation. A front-desk staff member schedules a real patient appointment through Relay without a member of the Relay team in the room.

Timing. Set by onboarding capacity, not by the size of the market.

Output. Month-twelve revenue as a function of the share that activates, the share of those that pay, the price, retention, and the number of accounts the team could have onboarded by then — written as a sentence with conditions attached, not as a total.

Both open items are named on the page where a reader will see them, but only one of them has work directed at it. The pricing unit is what the second page is built to move: presenting a priced offer at a stated unit and recording acceptances and declines is how an open decision becomes an observation. The replace-or-sits-alongside question is not moved by either page as written, and the honest handling is to say so on the slide rather than leave a reader to assume it's settled. An item nothing in the deck will test is still allowed — it just has to look like what it is, an open question with no work pointed at it yet.

Two unresolved decisions and four placeholder rates look weaker than a curve. They're actually more informative, because a reader can see where the risk sits. A curve tells the reader what the answer is and hides what the answer depends on.

Compare a milestone-and-resource explanation

The second document answers a different question: given the uncertainty, what work is the company going to do, with what, and what will it know afterward?

Its shape is consistent. For each important unresolved question, state the bounded work that would reduce it, the resources the work requires, and the evidence it's intended to produce. Then state what that evidence still won't settle.

The distinction that carries the whole section: completion is not validation. A finished prototype proves the team can build. A completed pilot proves what those clinics did under those conditions, with that support, over that period. Neither is demand. A milestone list that implies otherwise is doing the thing this article is about, with a project plan instead of a chart.

There's a related disguise worth naming. A phase-by-phase list with dollar amounts attached to each phase is a spending plan. That's a legitimate and useful document — it's just not a forecast, and it can't be relabeled as one by adding a revenue column to the right-hand side. Milestones aren't triggers. "Once the integration ships, clinics convert" puts a fact under the team's control and a fact that isn't in the same sentence, joined by a comma.

Relay's second page, then.

What the money buys

Question one: can a front-desk staff member complete the scheduling task unaided? Work: a bounded pilot with clinics recruited from the conversations already held, over a fixed period. Evidence: whether the task gets completed, how much support it took, and where it stalled. Resources: engineering time to finish the onboarding flow, one person to recruit and onboard the clinics, and the clinics' own staff time.

Question two: will a clinic accept the proposed paid offer at the proposed unit? Work: present a priced offer at the end of the pilot; record acceptances, declines, and the reasons given. Evidence: what clinics did when asked for money at a stated price for a stated unit.

Still unknown afterward. Whether use continues once the team stops showing up. Whether a different clinic size or specialty behaves differently. What it costs to find the next cohort. How many clinics one hire can onboard. Whether the price that cleared at pilot scale holds at any other scale.

Nothing in that page is a revenue figure, and that's the point. It's a description of what the company will learn and what it will spend. Notice also that a successful pilot leaves most of the list above intact. Even a clinic that completes the task and accepts the offer is a clinic that did so inside a pilot, with the founding team nearby and the product's rough edges tolerated.

Choose what this funding conversation needs to inspect

The two documents answer different questions, which is the cleanest way to decide which one a given conversation is asking for.

Use the conditional model when the recipient's question is structural: what would have to be true for this to be a business, and does the size of the ask follow from that? The model exposes dependencies, capacity constraints, and the point at which the business stops working.

Use the milestone-and-resource account when the question is: why this amount, and what will exist at the end of it? It connects the money to a period of work and to a decision the company intends to be able to make afterward.

The two often belong on adjacent pages with their roles labeled. SBA's small-business planning guidance — "Plan your business," inspected 18 September 2026, at https://www.sba.gov/counseling/plan-your-business/ — lists the funding request and financial projections as related planning subjects, and treats the request as something to explain rather than something to chart. That's a modest point and it's worth keeping modest: it's US small-business guidance, it says nothing about pre-revenue traction or conversion, and it doesn't prescribe a presentation order. What it does support is the instinct to keep the request legible next to the numbers rather than implying that the numbers speak for themselves.

Label them on the slide. Model: conditional on the assumptions below. Plan: work funded by this round. The labels are cheap and they prevent the most common misreading, which is a reader taking the model as a prediction and the plan as a forecast.

What to leave out is easier to state. No probability of success. No benchmark conversion rate imported from "the industry," which is almost always a number from a different product, a different price, and a different channel. No top-down market figure divided by an unstated something. Those aren't conservatism, they're fabrication with a citation attached.

The funding relationship closes the loop. The ask should trace to the second page — the milestones are what the money buys — and the first page should show which of those milestones is meant to move which assumption. If the round funds a pilot, say which uncertainty the pilot addresses and what would count as an answer. Not what the answer will be.

Relay still has no revenue. Its deck can say that plainly, then say what would change it: two commercial decisions still open, two questions a bounded pilot is built to answer, and a set of rates that stay labeled as placeholders until something observed replaces them. None of that is a forecast in the sense the word usually carries. It's better than one. It tells the reader where the business is exposed and what the next dollar is for.

And the line that says no paid customers isn't a weakness to be managed on the way to the chart. It's the only sentence on the page that's fully supported.

Frequently asked questions

Why is a smooth pre-revenue revenue curve misleading even if the line itself is not a lie?

A curve is an argument about evidence. A smooth line from month one to month twenty-four borrows the visual grammar of a chart built from last year's invoices, so a reader cannot tell observed revenue from projection unless told. Turning interview notes into projected subscriptions is especially problematic: a conversation is not a payment, and a sentence is not a rate. The chart ends up borrowing a history the company does not have.

What can each kind of pre-revenue evidence actually support?

A working prototype supports a claim about product state, only as of a date. Interview notes support what people said in a conversation; eleven people saying they would probably use something is a record of eleven sentences, not an addressable market or conversion rate. Reported intent is still a report of speech, but closer to a decision. A signed agreement records willingness to participate in a defined activity, often for free and with conditions. A paid invoice is the first item that says anything about willingness to pay, and even that is one observation at one price under one set of circumstances. The deck should show the ladder rather than collapse it into “traction.”

What must a conditional commercial model account for, and why is the revenue total not its main value?

It must account for the customer, the offer, the unit the price attaches to, the event that counts as a paying customer, and timing driven by onboarding capacity. Each item can be settled or left visibly open. The arithmetic is R(t) = A(t) × a × c × p, and across cohorts month-t revenue sums earlier cohorts multiplied by activation, conversion, price, and survival. Because the expression multiplies, half any input halves the output; its value is the dependency structure. It shows where the business is most exposed and makes clear that a number without a is a number about a.

When should a team use a conditional commercial model instead of a milestone-and-resource plan?

Use the conditional model when the recipient is asking what would have to be true for this to be a business and whether the size of the ask follows from that. It exposes dependencies, capacity constraints, and the point at which the business stops working. Use the milestone-and-resource account when the question is why this amount and what will exist at the end of it; it connects money to a period of work and to a decision the company intends to be able to make afterward. The two often belong on adjacent pages with their roles labeled.

Why is completion not validation, and what can a successful pilot still leave unknown?

A finished prototype proves the team can build. A completed pilot proves what those clinics did under those conditions, with that support, over that period. Neither is demand. Even a successful pilot may leave unresolved whether use continues once the team stops showing up, whether a different clinic size or specialty behaves differently, what it costs to find the next cohort, how many clinics one hire can onboard, and whether the price that cleared at pilot scale holds at any other scale.

Further reading

• One Forecast or Several Scenarios? Show What Changes the Business Case — If one conditional model cannot hold the open questions, this compares cases that move a driver rather than scale every row, and asks what a reader would do differently.
• Show What Your Traction Actually Measures — Read this before you label an activation or paying-customer event on the model, since it settles the unit, qualifying event, period, and denominator first.