Burn Rate Explained, With the Formula, Real Benchmarks and What Actually Drives It

You open the bank account on a Monday morning and the number has moved further than you expected. The team is shipping. Features are going live. Standups are upbeat. And somewhere between the standup and the bank statement, the money is leaving faster than the product is arriving.

Burn rate is the speed at which a company spends its available cash reserves to cover operations before it reaches positive cash flow. Before your first paying customer, your net burn rate equals your gross burn rate. Who sets that number? Four decisions you make about the product, made weeks before anyone opens a spreadsheet.

An analysis of 431 venture-backed startups that shut down since 2023 found that 70% of those with an identifiable cause ran out of capital. Read the next line of the same analysis. Weak product-market fit appears in 43% of those cases and unsustainable unit economics in 19%, which is what emptied the account in the first place. The shares add to more than 100% because most of these companies were dealing with several problems at once.

What is burn rate, and why is it higher than you expected?

Burn rate is the speed at which a company spends its available cash reserves to cover operations before it reaches positive cash flow. It is measured on a monthly basis. Cash burn rate and monthly burn rate describe the same figure, and it is the first number anyone assessing your financial health will ask for. It answers one question, which is how much cash your company consumes every month to stay alive.

The number surprises founders because costs and progress run on different calendars. Salaries, infrastructure and tools are fixed costs that arrive on the first of every month, cheerfully indifferent to whether the product moved forward. They cover overhead costs that exist regardless of output. Your company's burn rate is written into contracts, and it keeps its own schedule whatever the roadmap does.

This matters more than any other metric at this stage. Among 431 venture-backed startups that closed since 2023, running out of capital was the most commonly identified cause. Your burn rate tells you how long you can sustain operations, and how much time you have left to be wrong about something and still recover.

What is gross burn rate?

Gross burn rate is the total amount of cash your company spends in a month, before counting any revenue. It covers all of your operating costs, from salaries and contractor invoices to cloud and hosting bills, software subscriptions, marketing costs and legal fees. To calculate gross burn rate you add all of it together and stop there.

Ask one question about every line you are unsure about. Did that money physically leave the bank this month? If the answer is yes, it belongs in your gross burn rate. Depreciation, accruals and invoices sitting unpaid in a drawer belong in a different report.

For a company still building its first product version, this is the only figure fully under your control. Customers arrive on their own schedule. Every operating cost that makes up this number sits inside a decision somebody on your team already made, which makes gross burn your working tool for maintaining financial health before revenue exists.

What is net burn rate, and does it matter before you have revenue?

Net burn rate is your monthly spend minus your monthly revenue. The net burn rate formula is simple, and to calculate net burn rate you subtract one number from the other. If you have no revenue yet, your net burn rate is your gross burn rate. The distinction that fills every article on this subject waits politely until someone pays you.

Once revenue arrives, the two numbers separate and net burn becomes the more useful one, because it shows the actual cash loss per month. A company spending 60,000 dollars and earning 20,000 dollars has a monthly net burn rate of 40,000 dollars, and that company's net burn rate is what drives its runway. Negative cash flow of that size is ordinary at this stage and dangerous the moment nobody is watching it.

Until then, treat the two as one number. Chasing the gap between gross burn and net burn before you have customers is arithmetic with a zero in it.

How do you calculate burn rate and your cash runway?

Add up every cash expense for the month to get your gross burn rate. Subtract that month's revenue and you have your net burn rate. Divide the cash you hold by your net burn rate and you get your runway in months.

Three formulas cover everything you need at this stage.

Gross burn rate equals total monthly cash expenses.
Net burn rate equals total monthly expenses minus monthly revenue.
Financial runway in months equals cash on hand divided by average monthly net burn.

Everything else in burn rate calculations is a variation on those three lines.

One warning about the arithmetic. Some sources write the gross burn formula as cash divided by monthly operating expenses, which produces a number of months. Check the unit before you trust the number. Burn rate lives in dollars per month, and runway lives in months.

What is the burn rate formula?

Gross burn is your total monthly cash expenses. Net burn is that number minus your monthly revenue. Getting from your bank statement to a figure you can trust takes five steps.

1. Export every cash outflow from the month, from every account and every card.
2. Remove one-off items such as an annual insurance payment or a laptop purchase, and spread them across the months they actually cover.
3. Repeat for the two previous months and take the average, so one strange month does not set the tone.
4. Subtract that month's revenue, if any, to get net burn.
5. Write the result down as a single monthly figure and update it on the same day each month.

Step three is the one everybody skips. Take a quarter with a conference, a legal bill and an annual subscription renewal all landing in the same four weeks, and you will produce a burn rate that looks like a small emergency. A burn rate calculated from one month is a guess wearing a decimal point.

How do you calculate your cash runway?

Divide your cash on hand by your average monthly net burn. The result is how many months you can operate before the account reaches zero. A company with 380,000 dollars in the bank and a net burn rate of 42,000 dollars a month has nine months of runway.

Runway turns your company's cash flow into something you decide about. Try reading every new fixed cost as a subtraction from your runway. That extra engineer at 12,000 dollars a month, against the same 380,000 dollars, moves you from nine months to seven.

Notice what happens to the conversation when you phrase it that way. Would you trade two months of your company's remaining life for one more engineer? That is the same question as twelve thousand dollars a month, asked in the currency that decides the outcome.

What is a burn multiple, and can you use it yet?

Burn multiple divides your net burn by your net new annual recurring revenue. It measures how much cash you consume to generate a dollar of new recurring revenue. With no revenue, the formula divides by zero.

The thresholds are worth knowing in advance. A burn multiple below 1.0 counts as excellent, from 1.0 to 1.5 as strong, from 1.5 to 2.0 as acceptable, from 2.0 to 3.0 as a question investors will ask about, and anything above 3.0 as a warning sign.

File it away somewhere you will find it. The moment your first recurring revenue arrives, this becomes the metric people judge you on, and learning the thresholds in a quiet month beats learning them halfway through a fundraising conversation.

What is a good burn rate for a startup?

There is no reliable public median burn rate by funding stage. What matters is whether your burn buys progress toward the one question your product needs to answer. A good burn rate moves you toward that answer faster than it moves you toward an empty account.

That is an unsatisfying answer, so here is how it was reached. Six of the organisations that publish benchmarks for early stage companies were checked for a median monthly burn by stage. None of them publishes one. One of them holds the transaction data that would make such a figure possible, and adds a note warning readers against reading its numbers that way.

Some proportions do exist for companies past the early stage. Across more than a thousand private business software companies, median spend on research and development sits at 22% of annual recurring revenue, with hosting and operations together accounting for another 9%. Those figures describe a business's burn rate at three million dollars of recurring revenue, which sits several stages ahead of where you are.

One comparison from the same data travels well across stages. Venture-backed software companies spend 101% of their recurring revenue while bootstrapped ones spend 96%, and yet 83% of the bootstrapped group operates at or near breakeven against 52% of the funded group. More capital arrives with a higher burn rate attached. Better use of the money arrives when somebody decides to make it arrive.

Why can you not trust the burn rate benchmarks you find online?

Most burn rate benchmarks in circulation have no published sample, no year and no methodology. They travel from blog to blog, gathering confidence with every hop.

The most widely repeated one claims that 82% of businesses fail because of cash flow problems. It sits on a page ranking in the top five results for this topic. Follow the citation and you find another article, which cites another article, which gestures politely toward a bank that nobody has ever named.

The same applies to median burn figures attributed to a well known equity management platform. That platform has never published a median burn rate by stage. What it published was spending capacity, meaning round size divided by the time between rounds, alongside a note explaining that this is a different thing entirely.

Three questions separate a benchmark from a legend. How many companies were measured? In what year? By what method? A number that survives all three can carry your financial strategies, so ask them of every benchmark you meet, including the ones in this article.

What is a high burn rate really telling you?

Every startup failure story ends the same way, with an empty account. Ask what happened in the chapter before. The same analysis that reports capital running out for 70% of the 385 companies with an identifiable cause also finds weak product-market fit in 43% of them and unsustainable unit economics in 19%. The money left because something had already gone wrong upstream of the money.

Try the thought experiment on a startup's burn rate. A company burns 55,000 dollars a month building a product nobody has confirmed they want. Cut that to 38,000 dollars and what changes? The runway stretches. The wall waits patiently at exactly the same distance, and the company reaches it a few months later, slightly more tired.

There is a catch, and it points the other way. Spending too little is its own failure mode, because a burn rate low enough to feel safe is low enough to be too slow to learn anything. So what makes a burn rate healthy? It buys answers.

Which leads to a monthly question worth putting on the agenda, and it is a better question than how much money went out. What is this month of spending supposed to prove, and did it prove it? Ask that one every month and your potential cash flow issues show up while there is still time to act on them.

Which decisions actually set your burn rate?

Four decisions set your burn rate while you build a first product version. How much you build. How many people build it. What it runs on. How many shortcuts you take. Those are your major cost drivers, and every one of them is a product decision that lands in the finance column. Scope is the cheapest of the four to change, and it sits at the bottom of most founders' lists.

Every one of these four decisions is made in the first weeks of building an MVP, and none of them gets named as a budget decision at the time. They happen in planning meetings, in hiring conversations and in architecture discussions, and each one quietly writes a line into the number you will stare at three months later.

The split between fixed and variable expenses runs straight through that table. Fixed expenses continue whether or not anything ships, while variable expenses rise and fall with what the product does. Read the reversibility row twice, because it explains most of the decisions founders regret once a burn rate starts to feel dangerous.

Which of these costs can you actually reverse?

Ask how long each decision takes to undo. Scope changes in an afternoon. Infrastructure changes in a day. A team takes months, and technical debt takes years. That single spread should decide the order in which you touch them.

Watch what happens when runway shrinks. A founder reaches for headcount first, because payroll is the biggest line and cutting it produces the biggest number on the slide. It is also the decision that charges you on the way in and on the way out, takes months to undo, and slows down everyone who stays behind to watch it happen.

Now look at the same moment from the product side of the table. Scope produces a smaller headline saving, takes effect this week, and costs nothing to reverse. Infrastructure behaves the same way, since a badly sized cluster can be resized on a Tuesday afternoon and the variable costs drop by Wednesday. Technical debt sits on its own, because it has already been written into the product and a decision cannot unwrite it.

How does product scope drive your burn rate?

Scope multiplies every other cost. Telemetry from 615 product subscriptions, measured over three months of real usage, found that 80% of features are rarely or never used, while 12% of features generate 80% of daily usage. A feature nobody opens gets paid for twice, once to build it and once every month it sits there being maintained.

Scope grows quietly because each feature looks cheap on its own. A login screen with three sign-in methods. An admin panel that could have waited. A settings page for preferences nobody has requested. None of them moves the estimate much. Together they move the number of engineers you need and the number of months you need them, which is how a team ends up spending money at twice the rate anyone planned.

Deciding how to define an MVP feature set that validates demand is the single cheapest thing you can do to your burn rate. It is also the one lever that works while your bank balance is still intact.

What belongs in the first version and what does not?

The first version needs whatever answers the one business question you are building it to answer. Everything else can queue up behind that answer.

• The feature that directly answers your business question, in its simplest working form
• The shortest path a user can take from arriving to getting value, with nothing decorative on it
• Whatever your legal environment requires, which in regulated domains such as healthcare software stays in the first version at any price
• A way to measure whether the answer arrived, because a launch you cannot read teaches you nothing
• Everything else, which is a choice you get to make later

That last line is the one worth arguing about internally. Ask the question out loud about every candidate feature. Does its absence stop you learning what you need to learn?

How do you decide what to cut without breaking the product?

Rank every feature by whether it changes the answer to your business question. Anything that leaves the answer untouched can wait. Rank first and debate quality later, because those are two different meetings.

A structured product discovery phase exists to force that ranking before anyone writes code. At Selleo, discovery cuts the scope of a first version down to what the business question actually requires, and across our own projects that has meant a 50% reduction in budget. That figure is our measurement of our own work, which puts it under the same three questions you should be asking of every number in this article. The largest financial decision in the whole project gets made in the weeks when nothing is being built yet.

Testing the idea with an interactive prototype costs a fraction of building the feature and answers the same question about whether anyone wants it. A prototype that kills a feature pays for itself several times over, because the feature it prevented would have carried a maintenance bill for as long as the product lived.

How does team size affect your burn rate?

Payroll is the largest single line in most startup burn rates and the hardest one to reverse. In a study of 3,200 technology startups published in 2011, companies that scaled prematurely carried teams three times larger than comparable companies at the same stage, and 93% of them never passed 100,000 dollars of monthly revenue. That finding has aged well, because the mechanism behind it has not changed.

A team grows for reasons that sound excellent in the room. Someone is a bottleneck. A skill is missing. A deadline is close. Each hire solves a real problem, and each hire converts a temporary problem into a permanent cost that will still be there long after the problem has gone.

Bringing in staff augmentation for a defined period keeps a specialist cost variable, so it ends when the need ends, well before the month you next raise money. Before every hire, ask whether this need will still exist in twelve months, because the cost certainly will.

How much does a first product version actually cost per month?

No credible study publishes the cost of building a first product version. Every figure circulating on this question comes from a company that sells the service, quotes no sample and names no year. Build the number yourself, from salary data, team size and time.

Start from what engineers cost where you plan to hire. A 2025 developer survey puts the median full-stack salary in the United States at 138,000 dollars a year and the median back-end salary at 175,000 dollars, against 85,428 dollars in the United Kingdom and 75,410 dollars in Germany. Add employer costs, tooling and infrastructure on top of that.

Then multiply by the team you actually need and the months you actually need them. Three full-stack engineers at the United States median come to 34,500 dollars a month in salary alone, before employer costs, tooling and infrastructure appear on the invoice. Advertised contract rates for a senior full-stack developer in Poland ran between 23,520 and 28,560 zloty a month across every job posting published there in 2025, which brings the same three people in far below the United States figure. The identical first version carries a different burn rate depending on which country the payroll runs in.

Does your technology choice change your burn rate?

Count your stack in people. Every framework decision quietly sets how many engineers you need and how quickly you can replace one of them. A technology decision is a hiring decision with a different job title.

A mature framework with a large talent pool means less code written from scratch and fewer people writing it. Conventions do the work that decisions would have done. Standard components do the work that custom ones would have done. All of it shows up as fewer engineer-months for the same product.

Now run the same year forward from a different starting point. A technology picked because one person on the team enjoyed it produces a product that only that person can maintain. When a stack has a small talent pool, every resignation becomes a budget event.

Why is your cloud bill growing faster than your user base?

Most early cloud spend pays for capacity nobody uses. Across more than 2,100 organisations measured in 2025, average processor utilisation in container clusters was 10% and memory utilisation 23%. Founders expect cash outflows here to track usage, because infrastructure counts as a variable cost. Picture what you are actually renting. A warehouse, with one box in it.

Analysis of real cloud billing data found that 83% of container spend went to idle resources, most of it infrastructure provisioned larger than anything running on it required. Resizing to what the product uses is the fastest way to boost efficiency in this line. A separate 2026 survey of 753 cloud decision makers put estimated waste at 29% of infrastructure and platform spend, which is their own estimate and the first increase after five years of decline.

Most of that waste disappears with a few hours of DevOps and cloud work, long before any pricing negotiation. This is the one place where you can reduce expenses in a week and leave the product and the team untouched. Check what you are using before you argue about what you are charged.

Some of the floor stays where it is. Compliance requirements in fintech software raise the infrastructure baseline before you have a single user, and the same holds anywhere personal or financial data is regulated. The same trap appears when choosing cloud for your MVP, where the cheapest option on paper carries the highest bill for leaving.

Does technical debt show up in your burn rate?

Technical debt works on your exchange rate. In a 2018 survey of more than a thousand developers, the average developer reported spending more than 17 hours a week on maintenance, debugging and refactoring. The same burn rate buys you a smaller amount of new product every month, while your financial performance stays reassuringly flat on paper.

That figure remains the most recent measurement of its kind, and nothing since has measured it again. A 2024 developer survey found technical debt named as the single biggest frustration by 62% of respondents, twice the rate of the next problem on the list.

The financial version of the same effect has been measured in large organisations, where between 10% and 20% of budgets earmarked for new products gets diverted into resolving technical debt. That figure comes from a survey of 50 technology leaders at companies above a billion dollars in revenue, so treat the proportion as a signal about the mechanism, which works the same way at every size. A budget for new work quietly becomes a budget for old work.

How do you know you are paying interest on technical debt?

When your team says everything takes longer while your burn rate has not changed, the interest payments have started. Look for it in the slope of your delivery, because that is where it lives.

A productivity problem and a technical debt problem look identical from the outside. Watch what each one does under pressure. A productivity problem eases the moment the team gets focus. Technical debt grows with every shortcut taken to buy that focus, which is how one decision made in a rushed week can still affect burn rate three years later.

Taking on debt deliberately is a legitimate move while you are still validating. Write the simplest thing that answers the business question, and plan the rewrite into the calendar. That is a debt taken on with your eyes open. Debt turns dangerous at the moment nobody remembers deciding to take it on.

How do you manage burn rate without slowing down?

Cut scope before you cut people. Why that order? A scope decision takes effect this week and can be reversed on Friday. A hiring decision takes months to undo and charges you at both ends. Reversibility decides the order, and the size of the saving gets a vote without a veto.

Managing burn rate at this stage comes down to seven rules.

If you have no revenue, calculate gross burn and treat it as your net burn, because both formulas produce the same number and the difference between them is arithmetic you can safely postpone.

If you have to reduce spending, start with scope. A feature removed this week stops costing money this week and can be added back whenever the business question changes. Before you have customers you cannot increase revenue, so scope is the only side of the equation with a handle on it.

If your first version has more than a handful of core features, rank them by whether they change the answer you are looking for. Telemetry across 615 product subscriptions found 12% of features generating 80% of daily usage, and this ranking is how you find your 12% before you build all the rest.

If you are considering more people before anyone has confirmed they want the product, wait. Startups that scaled ahead of their stage carried teams three times larger than their peers, and 93% of them never reached 100,000 dollars of monthly revenue.

If your cloud bill is growing faster than your user count, check utilisation before you check pricing. Average processor utilisation of 10% across more than 2,100 organisations means the money is buying capacity, and capacity has never signed up for anything.

If your team says everything takes longer while your burn rate is unchanged, that is technical debt talking, and cutting the team will make it louder.

If you raised capital and your burn rate rose in proportion, check what you bought. Venture-backed software companies spend 101% of their recurring revenue against 96% for bootstrapped ones, and far fewer of them operate near breakeven. A raise buys you the option to move faster, and spending it on speed is a separate decision you make again every month.

Notice what these seven rules have in common. At this stage you generate no revenue at all, so how much revenue you could generate belongs to a later chapter. Every one of them protects the time you have left to go and find your first customers. How you choose a software development company for a first product version decides how much of that burn turns into progress.

How often should you check your burn rate, and when should you raise?

Check your burn rate monthly and your runway every time you consider a new fixed cost. The standing advice for a seed round is to raise enough to reach your next fundable milestone, which puts the target at twelve to eighteen months of runway. Since it takes months to secure additional funding, let your runway set the start date and let your readiness catch up on the way.

A useful monthly question has been in circulation since 2015 and still works. Assuming your expenses stay flat and your revenue grows as it has over recent months, do you reach profitability on the money you have left? The answer tells you how much funding you need and when. Cash inflows that have not started yet make a poor foundation for a plan. If the answer is no, you know it now, in a quiet month, with options still open.

The arithmetic changes once revenue arrives. Net burn separates from gross burn, burn multiple becomes calculable, and customer acquisition cost joins the picture as a driver that did not exist while you were building. For a software as a service product, revenue growth against a growing customer base is what moves you toward reaching positive cash flow, and every month of revenue generation shortens the gap that additional funding has to cover. The same shift happens again with growth, which is why scaling an EdTech product is a different budgeting problem from launching one. A healthy burn rate shrinks against revenue as revenue appears.

Try our developers.
Free for 2 weeks.

No risk. Just results. Get a feel for our process, speed, and quality — work with our developers for a trial sprint and see why global companies choose Selleo.

Test our team

Share this offer