Build vs. Maintain: Where Engineering Time Actually Goes in a Scaling Business

Ask most founders how their engineering team splits its time between building new things and maintaining what already exists, and you'll get a guess, usually an optimistic one. Ask the engineers doing the work, and the honest answer is often uncomfortably different from the story leadership has been telling the board.

The four buckets engineering time actually falls into

Engineering effort in a scaling business roughly splits into new feature development, maintaining and supporting what's already shipped, paying down technical debt, and unplanned firefighting when something breaks. Most businesses only budget and talk about the first bucket. The other three are usually treated as background noise rather than resourced, tracked work, which is exactly why they tend to expand quietly until they're consuming far more capacity than anyone realised.

Why maintenance grows even when nobody decides it should

Every feature shipped adds to the surface area that has to be maintained: more code to keep working, more integrations to keep healthy, more edge cases that can break when something upstream changes. Nobody explicitly chooses to spend more time on maintenance each year. It grows as an automatic consequence of the product growing, and without a deliberate decision to resource it properly, it eats into the time that would otherwise go to new development.

Firefighting is the bucket that hides the true cost

Unplanned work, a production incident, a broken integration, a data issue that needs urgent attention, gets absorbed by whoever's available, usually at the cost of whatever they were meant to be building that day. Because it's unplanned, it rarely gets tracked as its own category. It just looks like the roadmap sliding, which again tends to be read as a delivery or people problem rather than a resourcing one.

What happens when the split isn't measured

Without visibility into this split, every resourcing conversation happens on guesswork. A board asking why the roadmap is behind schedule gets an answer shaped by whoever's explaining it, rather than by what the team's time actually went to. A founder deciding whether to hire has no reliable way to know whether more people would relieve the pressure, or simply add more people into the same maintenance and firefighting drag that's already consuming the existing team.

Why this split matters more than headcount

Two teams of the same size, with the same skill level, can have wildly different output if one spends 70% of its time on new development and the other spends 70% on maintenance and firefighting. Headcount is the easy number to look at because it's the one on the org chart. The build versus maintain split is the number that actually predicts output, and it's rarely tracked with the same rigour.

Getting an honest read

Getting a genuine, unbiased view of this split usually means asking engineers directly, over a period of weeks rather than one snapshot, and being willing to hear an answer that doesn't match the story that's been told upward so far. It also means treating maintenance and debt paydown as legitimate, budgeted categories of work rather than an embarrassing admission that the roadmap isn't 100% new features.

Once that split is visible, resourcing decisions stop being guesses. The business can decide, deliberately, whether to invest in reducing the maintenance burden, accept it as a cost of the product's current shape, or resource for it honestly rather than being surprised by it every quarter.