This question came up in a CTO community coffee today:
How much maintenance load should a software engineering team have? What % of their time should be spent on this?
The answer to this is, of course, “it depends.”
It depends on a lot of things - where your product is on the product’s lifecyle, where the company is in the company lifecycle, what your stack is built out of and runs on, your team composition, your risk and compliance requirements, your stability requirements….
We could simplify this and say 20-80%, with 100% and 0% sometimes but that doesn’t really help.
If you’re an early stage product startup - you’re still experimenting trying to find product market fit. Every single dollar you invest should be focused on trying to find the product and customers that will keep your business running. You only fix things when it’s very very very critical.
If you’re well into your growth period, with solid market fit, and customers who depend on your product and it’s nine 9 uptime SLA, a fair amount of your overall business effort is just “run the business” work - keeping the lights on. Maintenance.
Lets talk risk for a second -
If you’re building the next recipe database, your compliance requirements are zero, and your risk (to the business and customers) from an outage or data breach or data loss is fairly low.
If you’re building an internet connected O2 regulator for patients on oxygen, your risks are completely the opposite - extremely high.
If you’re a scrappy bootstrapped startup with 1 or 2 unpaid founders building product, the revenue risk is zero, and the reputation risk is near zero - the clients you have are your hero clients, they understand.
If you’re a Fortune 500 company, your revenue and reputation risks are, again, the opposite. But maybe your customers are still understanding, or your reputation is such that a small issue won’t hurt much?
When we talk about maintenance - we’re not talking about “fixing bugs” - bugs get fixed because there’s a clear and pressing business need.
We’re talking about the things that are not tied to feature work in support of your customers.
A short list of examples:
Just like your car, as your tech stack ages it’s going to require more work. If you stay on top of the maintenance and make it a regular part of your product and business day to day operations, this can often be done in small, incremental, easily consumed chunks.
When you don’t do the maintenance, it catches up to you and can feel like you can’t keep up. Falling 10 releases behind on your OS, 3 major breaking revisions behind on your programming language, 15 breaking changes behind on your framework. You find yourself in a technical debt nightmare, where every update becomes a massive, risky undertaking. Small, incremental maintenance becomes impossible, and you’re facing a complete system overhaul that could take months or even years.
The key is balance and proactive management. Maintenance isn’t just a cost center - it’s an investment in your product’s long-term health, reliability, and adaptability. The right maintenance strategy depends on:
There’s no universal “right” percentage of time to spend on maintenance. Instead, think of it as a dynamic, responsive process. Regularly assess your technical landscape, prioritize updates that reduce risk and improve performance, and build maintenance into your regular workflow.
Remember: A little maintenance today can prevent a massive reconstruction tomorrow.