DEV Community

SoftwareDevs mvpfactory.io
SoftwareDevs mvpfactory.io

Posted on Originally published at mvpfactory.io

Startup Economics: Modeling Your Runway When Every Dollar Is a Hiring Decision

---
title: "Startup Economics: Model Your Runway Before You Hire Engineer #3"
published: true
description: "Model burn rate, hiring curves, and ARR growth to decide if engineer #3 accelerates your startup or burns your last 6 months of runway. Model it first."
tags: architecture, performance, devops, cloud
canonical_url: https://mvpfactory.co/blog/startup-runway-modeling
---

## What We Will Build

A two-scenario financial model that tells you, with actual numbers, whether hiring engineer #3 right now accelerates your startup or quietly compresses your runway below the threshold you need to close the next round.

This is not a culture call. It is a math decision. Let me show you the framework I use in every early-stage engagement.

---

## Prerequisites

- A spreadsheet (Google Sheets or Excel)
- Your current MRR and cash balance
- Your total monthly OpEx broken down by category
- A realistic estimate of all-in salary cost for the hire you are considering

---

## Step 1 — Calculate Your Baseline Runway

Here is the minimal setup to get this working:

Enter fullscreen mode Exit fullscreen mode

Runway (months) = Cash in Bank / Net Monthly Burn
Net Monthly Burn = Total OpEx − MRR
Total OpEx = Salaries + Infrastructure + Other Fixed Costs


With those three formulas locked in, you have a living model. Every assumption you change will cascade through the rest of the analysis.

---

## Step 2 — Model the Hiring Curve as a Step Function

This is the part the docs do not mention. A new engineer does not contribute at Day 1. Model their ramp as a step function with linear interpolation across the window:

Enter fullscreen mode Exit fullscreen mode


python
def arr_contribution(month, hire_month, ramp_months=3, monthly_arr_uplift=5000):
if month < hire_month:
return 0
months_since_hire = month - hire_month
if months_since_hire < ramp_months:
return monthly_arr_uplift * (months_since_hire / ramp_months)
return monthly_arr_uplift


Linear interpolation over 90 days is the conservative, auditable default. It avoids overstating early contribution. Stress-test the ramp assumption at 60, 90, and 120 days — it is the most sensitive input in the model.

---

## Step 3 — Run the Two-Scenario Comparison

These are the explicit assumptions for the comparison below: **$700K starting cash; $40K/mo current net burn; $15K/mo all-in new hire cost; 3-month ramp with zero revenue contribution; $7K/mo net burn reduction post-ramp as the hire drives incremental MRR; starting MRR $20K/mo growing at 3%/mo organically, accelerating to 6%/mo once the hire is fully productive.**

| Scenario | Month 6 Cash | Month 12 ARR | Runway at Month 12 |
|---|---|---|---|
| Hire Eng #3 now | $391K | $444K | 2.1 months |
| Defer to Month 6 | $460K | $373K | 3.1 months |
| No hire | $460K | $342K | 5.5 months |

Hiring now produces $71K more ARR at month 12. It also leaves you with 2.1 months of runway — almost no margin to close a round. The runway delta between hiring now and deferring six months exceeds one month. The case for waiting is strong.

---

## Step 4 — Track Your Burn Multiple

Operate as if the next check is not coming.

Enter fullscreen mode Exit fullscreen mode


plaintext
Burn Multiple = Net Burn / Net New ARR


| Burn Multiple | Signal |
|---|---|
| < 1x | Elite efficiency |
| 1x – 1.5x | Healthy |
| 1.5x – 2x | Acceptable — watch closely |
| > 2x | Danger zone |

If hiring engineer #3 pushes your burn multiple above 2x for more than two consecutive quarters, you are buying ARR with borrowed time. Track this quarterly, not annually. A spike above 2x for one quarter is a warning. Two consecutive quarters is a crisis.

---

## Gotchas

**Overestimating the ramp.** This is the most common error I see in early-stage financial models. Using a cliff step at Day 1 instead of linear interpolation inflates projected ARR contribution by 30–50% in the first quarter. Use 90 days as your floor.

**Conflating attrition cost with hiring cost.** If your existing engineers are at capacity, the relevant comparison is not "hire vs. defer" — it is "hire vs. replacement cost of losing someone." Those are very different numbers.

**Headcount as a velocity proxy.** In financial models across 20+ seed-stage teams, the correlation between engineers hired and features shipped is weak in the first 90 days — and sometimes negative. The model keeps you honest.

**Hiring ahead of capital.** There are three legitimate reasons to hire despite the math: a critical path skill blocker exists, attrition risk is real, or you have a signed term sheet. Outside those conditions, extend the runway.

---

## Conclusion

The two-scenario model is a 30-minute spreadsheet exercise that forces honesty about your ramp assumptions and burn trajectory. Run "hire now" vs. "defer N months" before every headcount decision, reconcile every figure against your stated inputs, and build your burn multiple into the board deck from the start.

The math does not make the decision for you. It makes sure you are not surprised by the answer six months later.
Enter fullscreen mode Exit fullscreen mode

Top comments (0)