Burn rate math: what your team structure does to runway
Fixed engineering payroll is the biggest lever on a seed-stage burn rate. Worked scenarios showing how team structure changes runway by six months or more.
Runway is cash divided by monthly burn. Every founder knows the formula. Fewer sit with the uncomfortable corollary: for a pre-revenue software company, the burn side is mostly engineering payroll, which means team structure is the biggest runway lever you control.
This post runs the numbers on three ways to structure the same team. The scenarios are simplified on purpose. We ignore rent, tools, and founder salaries (they don’t change between scenarios) and look only at the engineering line, because that’s the line that moves.
One more disclosure: we sell flexible engineering capacity, so the conclusion won’t shock you. The inputs are all here so you can disagree with arithmetic instead of vibes.
The setup
A seed-stage company with $600,000 allocated to engineering over the next phase. The roadmap for the next 12 months, if you’re honest about it, looks like most roadmaps:
- A 3-month push to rebuild the product for launch (needs ~3 people)
- A quieter 3 months of iteration and bug-fixing after launch (needs ~1.5 people)
- Another 3-month push for the second market (needs ~3 people)
- 3 months of steady state while you fundraise (needs ~1.5 people)
Average need: 2.25 people. Peak need: 3. The gap between those two numbers is where the money goes.
Scenario A: hire for the peak
Three full-time engineers so that pushes are covered. Using the fully loaded math from the true cost of hiring, call each ~$17,500 a month in steady state (we’ll be kind and skip recruiting fees).
- Monthly engineering burn: $52,500, every month, regardless of phase
- $600k lasts: 11.4 months
- Utilization in the quiet phases: 50%, which is ~$26,000/month of paid-for capacity with nothing urgent to do
Nothing catastrophic happens in scenario A. The team is good, the pushes go fine. You just paid peak price for average need, and it cost you the option of a longer runway. (Idle engineers also invent work. Some of it is refactoring you needed. Some of it is a Kubernetes migration you didn’t. That cost is real but we won’t put a number on it.)
Scenario B: hire for the average
Two full-time engineers, ~$35,000 a month. On paper: $600k lasts 17 months. In practice the pushes are now understaffed, so one of three things happens:
- The pushes take 5 months instead of 3. Launch slips. The market doesn’t wait, and the runway you saved gets spent anyway, on time.
- You crunch. Two people do three people’s push, twice in a year. Sometimes works once. The bill arrives later, as attrition, and replacing a burned-out engineer costs a quarter (see the miss math in the hiring-cost post).
- You panic-hire contractor help mid-push at whatever rate the week demands, unvetted, with no time to onboard them properly.
Scenario B is the most common one we see, and its failure isn’t visible in the spreadsheet, because the spreadsheet doesn’t have a “launch slipped eight weeks” row.
Scenario C: a fixed core plus an elastic edge
One full-time senior engineer as the core: the context-keeper, the person the codebase belongs to. Around them, capacity booked to match the phase. Using our from-rates as the reference (full-stack from $350/day, QA from $250/day, DevOps from $450/day):
| Phase (3 months each) | Structure | Monthly cost |
|---|---|---|
| Launch push | Core + 2 full-stack booked full-time | $17,500 + $14,000 = $31,500 |
| Post-launch quiet | Core + ~5 booked days/week across QA and full-stack | $17,500 + $7,000 = $24,500 |
| Second push | Core + 2 full-stack + DevOps 2 days/week | $17,500 + $17,600 = $35,100 |
| Steady state | Core + ~4 booked days/week | $17,500 + $5,600 = $23,100 |
- Average monthly engineering burn: ~$28,550
- $600k lasts: ~21 months
- Push phases are fully staffed. Quiet phases cost quiet-phase money.
Against scenario A that’s roughly nine extra months of runway for the same $600k, with the same peak capacity when it mattered. Against scenario B it’s four extra months and the pushes were actually staffed.
The objections, because you’re thinking them
“Booked people don’t know my codebase.” True, and it’s the strongest objection. It’s why scenario C keeps a full-time core: continuity lives there. It’s also why the elastic edge has to be the same people returning each booking rather than a rotation of strangers. That requirement rules out some providers; the model still holds. We wrote more about making the seams work in running a fractional team.
“Day rates are higher than salaries.” Per day, usually yes. Per used day, usually no. $350/day booked at need beats ~$800 to $1,000 per productive day of a fully loaded salary the moment your utilization drops under about 60%, and variable roadmaps drop it under that more often than founders expect. The math is in the true-cost post; plug in your own utilization before believing anyone’s summary, including ours.
“What if I can’t get capacity when the push starts?” A fair worry with freelancers, who are booked when you need them and free when you don’t. A standing network with a scale-up commitment is the fix; ours is 48 hours from booking to start. Ask any provider for their number and hold them to it.
Why this matters more than most line items
Runway buys more than survival. It sets your negotiating position. Raising your next round with four months left prices differently than raising with nine, because desperation shows up in term sheets. Nine extra months at the same output is strength at the table where your company’s ownership gets decided, which is worth more than the line-item savings that produced it.
And the lever compounds with stage. At $600k of engineering budget the structures differ by months. At a $2M budget with a five-person peak, run the same table and the gap gets embarrassing.
Run it for your own company
Ten minutes with a spreadsheet:
- Write your next 12 months as phases with honest headcount needs. (The honesty is the hard part. Roadmaps are spikier than founders admit.)
- Price scenario A: peak headcount × fully loaded monthly cost × 12.
- Price scenario C: your minimum continuous need as hires, the rest at day rates × the days each phase needs.
- Divide your budget by each. The difference is your runway gap, in months.
If the gap is small, your workload is steady and you should hire, full stop. If it’s six months or more, the week planner on our site prices the elastic edge in about ninety seconds, which is faster than the spreadsheet you were about to build.
