A founder in an accelerator cohort said it plainly on a call this autumn: building the model was not the hard part. His AI assistant had produced three versions in seven minutes. The hard part was making it realistic. What share of revenue goes into marketing? Into the rest?
It is the right question, and the standard answer does not work for him. Benchmarks for SaaS spending are expressed as a share of revenue: the median private B2B SaaS company spends 8% of its ARR on marketing and 15% on sales, according to SaaS Capital's 2026 survey of more than 1,000 companies. Apply 8% to zero and you get zero.
This article is about what to do instead: how to build assumptions that hold up before there is any revenue to take a percentage of, and when to switch to the ratios.
Why ratios fail before revenue (and are easy to misuse after)
A ratio to revenue answers the question "for a company of this size, how is spending usually split?" It describes companies that already sell. Before revenue there is no size, so there is nothing to split.
Three other traps sit in the benchmarks themselves, and they matter as soon as you start using them:
- The denominator changes from one source to another. One survey reports a percent of ARR, another a percent of GAAP revenue, another a share of operating expenses. "About 25% of opex on sales and marketing at $0 to $1M of ARR" (Scale Venture Partners) and "8% of ARR on marketing" do not measure the same thing and cannot be combined.
- Medians do not add up. In SaaS Capital's data, the department medians sum to 86% of ARR while the median total spend is 96% to 101%. A budget built by stacking medians is a budget no real company has.
- Funding changes everything. Equity-backed companies spend twice as much on marketing as bootstrapped ones at the median (10% of ARR against 5%), and 70% more on sales. Which group you compare yourself with is a choice, and it should be written down.
So the ratios are useful, but later, and as a check. Before revenue, the model has to stand on quantities.
Start with the people
In an early software company, most of the money goes to people. The Scale Studio dataset shows early-stage companies putting most of their operating spend into R&D, which at that stage means engineers. So the first assumption to fix is not a percentage. It is a hiring plan.
For each role, four things:
- The role (engineer, sales, customer success, finance).
- The start month. Not "in year 1": a month. Hiring takes time, and a model that adds three people on 1 January is optimistic by construction.
- The loaded cost: salary plus employer charges, benefits and equipment. Use the actual figure for your country. Employer charges differ a lot between France, Germany, the UK and the US, and a model built on gross salaries understates the cost of every hire.
- The trigger: what has to be true for the hire to happen (a funding round closed, a number of customers reached, a product milestone shipped).
The trigger is the part founders leave out, and it is the most useful. A sales hire conditioned on "10 paying customers" links cost to traction in a way an investor can follow. A sales hire in month 4 because the template had one in month 4 links it to nothing.
Once the team is fixed, the other cost lines become easier to defend: tools and hosting per person or per customer, office or none, legal and accounting as a monthly amount you can get quotes for.
Let the cash decide the marketing budget, not a benchmark
Without revenue, the marketing budget is a decision about how to spend the cash you have, not a ratio. Three inputs:
- How much cash, and for how long. The amount raised (or the savings committed) and the number of months it has to last before the next milestone. That is the real constraint, and it is a quantity.
- What marketing has to prove. Before revenue, marketing spend buys information: which channel brings a qualified conversation, at what cost. Budget it as a series of tests, each with an amount, a duration and the result that would count as a success.
- The cost of a customer you can afford. Work backwards from price. If a customer pays a known amount per year and keeps a known gross margin, the CAC payback you are willing to accept tells you the most you can spend to acquire them. The median CAC payback in 2025 was 16 months across 342 B2B SaaS companies (Aleph and Benchmarkit), with wide variation by deal size. That median is not your target, but it tells you what "normal" looks like, and the formula gives you a ceiling.
Write the result in the model as an amount per month, not as a percentage of a revenue that does not exist yet.
Build revenue from customers, not from the market
The weakest line in most pre-revenue models is revenue built top-down: a market worth billions, a small percentage captured, a large number. Nobody can challenge it, which is exactly why it convinces nobody.
Build it bottom-up instead:
- New customers per month, from the funnel you can describe: conversations per month, conversion to trial, conversion to paid. Each step is an assumption, and each one can be tested in the next three months.
- Price, from what you actually quote. If you have no price yet, that is the first thing to fix, before the model.
- Churn, as a monthly rate. Pick one, write down why, and expect to change it.
- Expansion, at zero to begin with. Net revenue retention above 100% is common in the benchmarks for companies with revenue (High Alpha's 2025 report puts the median at 100% under $1M of ARR), but a pre-revenue model that counts on expansion is counting on a customer base it does not have.
The test of a revenue line is simple: can you say how many customers you have in month 12, and how you got them? If yes, someone can disagree with you, and that discussion is worth having.
Write the source next to the number
Every assumption in a pre-revenue model is a guess. That is fine. What is not fine is a guess nobody can trace.
For each assumption, keep three things in the model, next to the number:
- Where it comes from: a quote from a supplier, a salary survey, a benchmark (with its year and its denominator), a test you ran, or "our judgement" said honestly.
- When it was set. A churn rate set before the first customer and never revisited is a common source of a model that looks precise and is not.
- What would change it. "Revisit after the first 20 customers."
This is also what makes the model usable by an AI assistant over several sessions. An assistant asked to "make this more realistic" will happily replace your numbers with plausible-looking ones. If each number carries its source, you can see what it changed and why, and refuse it.
When revenue arrives, switch to the ratios
The ratios come back into play once there is revenue to divide by. From then on, compare your model with the benchmarks for your stage and your funding:
- gross margin against the range for your ARR band (74% at the median under $1M of ARR in High Alpha's 2025 data, with early-stage margins down nearly 10 points in a year, which the report attributes to AI costs);
- total spend as a share of ARR against bootstrapped or equity-backed medians, whichever matches your plan;
- CAC payback, growth and net revenue retention against the medians for your segment.
A deviation is not an error. It is a question: either your plan has a reason the median company does not, or an assumption needs another look. The companion piece covers that check step by step: Sanity-Check a SaaS Financial Model Against Benchmarks. The figures, with their samples and denominators, are on the SaaS spending benchmarks page.
Where Layerz sits in this
Layerz will not tell you whether your assumptions are realistic. It checks that a model is coherent (every formula resolves, every line links to what it depends on, no hidden values break when an assumption changes), not that its numbers are right. It has no built-in benchmarks today.
What it does is the part this article asks for. Layerz is a structured spreadsheet built for AI: assumptions live in their own section, each item can carry a note with its source and date, and every line in the P&L or the cash flow traces back to the assumptions it uses. Scenarios live in branches, so "conservative" and "base" are two versions of the same model rather than two files. Claude drives it over MCP, so you can ask it to build the hiring plan or the funnel and see exactly which assumption it touched. The model exports to Excel with live formulas when an investor wants to open it.
Further reading: SaaS Spending Benchmarks (2026) · Sanity-Check a SaaS Financial Model Against Benchmarks · How to Stop AI From Hardcoding Values in a Financial Model · Fractional CFO Financial Model Template
Layerz keeps a financial model as structure separate from data. Claude writes the formulas, the engine calculates, and every number traces back to its formula. Excel export is clean, standard, and never paywalled. Explore Layerz →