Product and engineering · Answered by Golden Section from more than 400 B2B software companies observed
Your engineering team is probably too large when R&D spending runs above 20% of revenue without a dated initiative to explain it, and delivery has not risen with headcount. We hold R&D under 20% of revenue; the private B2B SaaS median is 22% of ARR. The other tell is a team waiting on work: sprints start without ready user stories, or engineers are building things no core customer asked for. It is probably too small when the reliability lane never gets capacity, defects reach production faster than they are fixed, and committed work slips quarter after quarter. Be careful with the complaint that you are too thinly staffed; every software company is, and it is a prioritization signal more often than a hiring one. Next step: put R&D as a share of revenue beside your successful sprint ratio for the last four quarters.
Size engineering from the budget and the roadmap, then check it against our view that R&D should stay under 20% of revenue. Add engineers when committed work and the reliability lane are both short of capacity; hold or shrink when spend rises while delivered output stays flat.
| Metric | Value | What it means | Source |
|---|---|---|---|
| R&D spend, Golden Section view | under 20% of revenue | research and development expense as a share of revenuefor $1–8M ARR vertical software companies; above it needs a dated, board-approved initiative | Golden Section operating viewGolden Section operating view |
| Engineering model at $1M ARR | development partner plus a technical lead | how engineering is staffed at the early stagean all in-house team is rarely reasonable this early | Golden Section operating viewGolden Section operating view |
| R&D spend, private B2B SaaS median | 22% of ARR | research and development expense as a share of ARR2026 survey of more than 1,000 companies; 24% at $3M to $5M ARR; equity-backed companies spend 56% more on R&D than bootstrapped ones | External benchmarkSaaS Capital, 2026 Spending Benchmarks for Private B2B SaaS Companies |
| ARR per employee, $5M to $10M ARR | $152,295 equity-backed; $177,240 bootstrapped | median ARR per full-time employeea company-wide check; a falling trend with flat delivery points to hiring ahead of the business | External benchmarkSaaS Capital, 2026 Revenue Per Employee Benchmarks for Private SaaS Companies |
| Implied R&D budget at $10M ARR | about $2.2M | 22% of $10M ARRarithmetic on the median, not a target; the headcount it buys depends on fully loaded cost and how much work is outsourced | IllustrativeGolden Section calculation |
| Engineering allocation in the AI era | about 45% core, 45% AI-native features, 10% skunkworks | share of engineering and product resourcesa test of whether the team is working on the right things before asking whether it is the right size | Golden Section, publishedThe Enhancement Doctrine |
Engineering headcount is easy to add and hard to read. Each request sounds reasonable, the cost arrives immediately, and the output shows up a release later, if it does. A team can grow while delivering less, because more people means more coordination and more stories waiting on the product manager and analyst. That is why the budget should carry engineering as initiatives with owners, and why the size question is answered by sprint output from the product engineering process rather than by headcount ratios.
An engineering team that looks too large is often unbalanced instead. Ten engineers fed by one overloaded product manager will look idle and slow, and the fix is an analyst or a clearer dev org chart, not cuts. A team that looks too small may be spending a third of its time on avoidable defects. Measure what it costs to deliver, not what it costs to employ: an expensive team that ships is cheaper than a cheap one that does not.
The figures are invented. A company at $5M in annual revenue employs 16 engineers and spends 38% of revenue on R&D, against a 22% median and our view that it should stay under 20%, with no dated initiative behind the gap. Over four quarters headcount rose by five while the successful sprint ratio stayed flat near 55%. Reviewing the dev org chart shows one product manager writing stories for three teams, so engineers routinely start sprints with half-ready work. The company hires a business analyst, consolidates three teams into two, does not backfill two departures, and gives the reliability lane fixed capacity. R&D falls toward 30% of revenue over the year while delivered stories rise, and the board sees a plan for the rest of the gap.
Under 20% of $1M is less than $200,000, which buys very little in-house engineering, so expect a development partner rather than an in-house team. Some companies run above that share while the product is being built; the question is whether the founder or a technical lead owns architecture and the partner's output.
The median rises slightly to 24% of ARR. This is where a product manager, analyst and technical lead usually become separate seats, and where unbalanced teams first show up as slow delivery.
Under $2M at our 20% ceiling, about $2.2M at the median. By now engineering should be organized as teams around modules with sprint metrics reported monthly, and the budget should show what share is core, AI features and new products.
A company building a product the market has not yet seen, or rebuilding its platform with board approval, will run R&D well above the median for a period, and that is fine with a dated plan. Vertical companies that outsource engineering will show lower internal headcount for the same output.
From the Golden Section mistakes list, each paired with the play that prevents it.
An all in-house team at $1M ARR is rarely reasonable; a good development partner covers the work and backstops turnover.
Every software team feels too thinly staffed, so the complaint alone is not evidence for hiring.
Judging engineering by its cost per head instead of its cost per delivered output leads to the wrong size in both directions.
Cutting engineering to hit a benchmark can underfund the product that carries the company.
In the order we would run them. Each is on its own page, most with a free Excel template.
Makes every engineering hire trace to an initiative with an owner.
Shows whether the team is the wrong size or the wrong shape.
Provides the sprint metrics that measure output rather than activity.
Puts R&D spend and delivery on the same weekly page as the rest of the business.
Development plays The org chart, engineering process and architecture plays that determine how much a team delivers.
Fewer in-house than founders expect. Under 20% of revenue, a $1M company has less than $200,000 a year for engineering, so at this size we would expect a technical lead working with a development partner rather than an in-house team. Some spend above that share for a dated period while the product is still being built.
Start from the budget rather than a count. Our under-20% view implies less than $2M, and the 22% median about $2.2M; the number of people it buys depends on fully loaded cost and how much work is outsourced. Check that each engineer maps to a roadmap initiative and that delivered output is rising with the team.
Committed work slips for several quarters, the reliability lane gets no capacity, and production defects pile up faster than they are fixed, even though ready work is waiting. If the team is idle for lack of ready stories, it is not too small; product management is.
Running R&D above 20% of revenue for a dated, board-approved rebuild or new product is a legitimate use of growth equity. Running it there without a plan is a cost problem to fix before raising.
Growth equity →Reviewed by Dougal Cameron, CEO & Co-Founder on 2026-10-22. Golden Section observations are labeled separately from external benchmarks and illustrative arithmetic.