Software maintenance budget founders can defend with the team

Why all engineering time looks the same on paper

On a budget sheet, engineering often appears as one number. It looks neat, but it hides very different jobs.

A founder sees a total cost and hears, "engineering needs this much." What they do not see is how much of that time keeps the product stable, how much builds the roadmap, and how much lowers the chance of bigger problems later.

That is where budget conversations go off track. If every hour looks the same, then a database upgrade, a customer bug fix, and a new feature all compete inside one vague pool. The team knows the difference. The budget does not.

In a normal week, engineers might fix a live issue, ship a planned feature, update old libraries before they break, and handle support requests that were never planned. All of that costs money. None of it solves the same problem.

When founders hear only one total, they can only argue about the total. They cannot question tradeoffs well because the work has not been named clearly. If the team asks for more budget, the next question should be simple: what kind of work is it for?

Engineers add to the confusion too, usually by accident. Urgent fixes end up in the same conversation as feature delivery because the same people do both. A sprint can look busy on paper while half the week disappeared into incident cleanup.

A maintenance budget gets much easier to defend when it stops acting like one bucket. Once you separate work by purpose, the conversation changes. A founder can see what protects revenue now, what tries to grow it later, and what lowers the odds of an ugly surprise next quarter.

That does not solve every planning fight. It usually lowers the temperature. People stop debating a mystery number and start discussing real choices.

The three buckets that make the budget readable

A budget gets easier to defend when the team stops treating every engineering hour as the same kind of work. One hour spent fixing a production issue does not do the same job as one hour spent building a new feature. Put both in one pile, and planning turns into guesswork.

Use three buckets, and keep the rules plain enough that anyone in the room can apply them.

• Keep the lights on: work that keeps the current product usable today. Think support tickets, bug fixes, routine updates, incident response, broken integrations, and urgent performance problems.
• Roadmap: work that adds new capability. This includes planned features, product bets, and customer requests you chose to build.
• Risk reduction: work that lowers the chance of future outages, security issues, or expensive rework. This covers patches, backup checks, test coverage, monitoring fixes, access reviews, and cleanup in fragile parts of the codebase.

The test is simple. If users feel the pain now, it is keep-the-lights-on work. If the work adds something new, it is roadmap. If it lowers future risk, it belongs in risk reduction.

This split fixes a common mistake. Teams often hide security fixes and cleanup inside general maintenance, then wonder why feature delivery feels slow and unpredictable. Risk reduction is different work with a different purpose. It needs its own line.

The split also makes tradeoffs easier to discuss. If someone wants to cut engineering spend, ask which bucket they mean. Few founders want less incident response. Some may accept fewer product bets for a quarter. Others may delay cleanup, but only after they see the risk clearly.

Keep the rules short and use them every planning cycle. If a task seems to fit two buckets, ask why the team is doing it. The main reason usually tells you where it belongs.

What belongs in keep-the-lights-on work

Founders usually undercount this bucket because it arrives in small pieces. A bug fix takes two hours. A library update takes half a day. A release needs extra checking. None of it looks dramatic on a planning sheet. It still belongs in the budget.

Start with anything that keeps customers doing normal work right now. If users cannot log in, send invoices, upload files, or finish checkout, fixing that problem is not optional cleanup. It is operating work. The team should count it before anyone promises more features.

The same goes for regular upkeep that users may never notice. Teams spend real time on package updates, server patches, database care, SSL renewals, cloud cost checks, and vendor changes forced by an API update or pricing change. You may never market that work. You still pay for it.

Support work counts too when it keeps revenue moving. If sales needs help setting up a trial for a serious prospect, or customer success needs engineering to fix a broken import for an existing account, that is part of keeping the business running. Founders often call this "just a quick assist" and then wonder where the week went.

Do not forget on-call time. Someone watches alerts, checks logs, answers urgent messages, and stays close after releases in case something breaks. Even if nothing fails, that time has a cost because the engineer cannot use it with full focus on roadmap work.

A simple rule works well here: if the team must do the work to keep the current product usable, supported, and stable, count it.

That usually includes:

• user-blocking bug fixes
• routine infrastructure and dependency updates
• vendor-driven changes
• support tasks tied to active customers or sales
• on-call coverage and post-release follow-up

Once you count these hours honestly, planning gets less emotional. A feature did not "slip" because engineering moved slowly. Part of the week went to work the company needed in order to keep shipping at all.

Roadmap work needs stricter rules

Roadmap work tries to change the business. It should not live under the same rules as bug fixes, support, or routine upkeep. When a founder treats all engineering time as one pool, every debate turns vague and the loudest request usually wins.

Each roadmap item needs a clear reason to exist. Tie it to a product or revenue goal. "Build team permissions" is weak on its own. "Build team permissions so larger customers can buy the higher plan" is a budget line people can defend.

If nobody can name the goal, the item is still an idea, not roadmap work. That sounds blunt, but it saves teams from spending six weeks on something users never asked for.

Small estimates beat grand plans

Small teams should estimate roadmap work in chunks they can actually track. Long, fuzzy epics hide delays and make progress look better than it is. Break the work into parts that fit a short planning cycle, such as discovery, first release, and follow-up changes after real use.

Take a reporting screen for a SaaS product. Instead of estimating one eight-week project, split it into a short prototype for internal review, a basic version for a handful of customers, and a second pass only if people use it.

That structure makes tradeoffs easier. It also leaves room to change direction after early feedback, which happens more often than most plans admit.

Do not bury upkeep inside roadmap estimates. If the team needs dependency updates, test cleanup, or database work to ship a new screen, label that work honestly. Put product-facing work in roadmap. Put upkeep in keep-the-lights-on work or risk reduction.

Teams that hide upkeep inside feature numbers create two problems at once. The roadmap starts to look more expensive than it really is, and maintenance work disappears from planning. Months later, someone asks why uptime, speed, or support load got worse. The answer often starts inside a messy estimate.

Risk reduction work still needs a budget line

Risk reduction rarely ships a feature, so founders often cut it first. That is a mistake. If you leave it for "when the team has time," it usually does not happen until something breaks.

This bucket covers work that lowers the odds of outages, security problems, and expensive surprises. The payoff is fewer bad weeks, fewer fire drills, and fewer awkward calls with customers.

Common examples include:

• security patches for libraries, servers, and third-party tools
• backups, restore checks, and access reviews
• fixes for parts of the product that fail every release
• tests, monitoring, and recovery drills

Teams often hide this work inside general maintenance. That makes planning messy. A bug fix after every release is not random support work if the same module keeps failing. It is a risk problem, and the budget should treat it that way.

The same is true for backups. A backup nobody tests is just hope. If the team has never practiced restoring data, they do not know how long recovery will take, what will break, or who needs access during an incident.

Put a price on delay

Founders defend roadmap work easily because they can point to revenue. Risk reduction needs the same plain language.

Do not say, "we need better monitoring." Say what delay costs. If a checkout bug takes six hours to detect, that is six hours of lost sales. If an old dependency fails a customer security review, the deal may stall. If one engineer still has admin access after changing roles, the company carries a risk no serious buyer likes to see.

A small team can estimate this without heavy process. Ask four questions:

• What breaks often enough to waste time every month?
• What security or access task is already overdue?
• How long would recovery take if the main database failed today?
• Which weak spot could block a sale or renewal?

Even a lean team should reserve time for this work every cycle. Oleg Sotnikov at oleg.is has spent years running production systems with lean teams, and the lesson is simple: high uptime comes from planned prevention, not heroics.

How to build the split

Start with evidence, not guesses. Pull the last quarter of tickets, incident notes, meeting notes, contractor invoices, and even calendar entries from senior engineers. A lot of maintenance work never makes it into the sprint board, and that gap is why founders often underestimate it.

Then sort each item into the three buckets. Keep the rules simple. If the work kept the product running, fixed bugs, handled support, renewed dependencies, or dealt with small breakages, it belongs in keep-the-lights-on work. If it shipped something customers can notice, it belongs in roadmap. If it lowered the chance of a future outage or security problem, put it in risk reduction.

When people disagree, ask why the team did the work. The reason usually makes the bucket obvious.

Now total the cost of each bucket. Count internal hours, contractor time, and recurring tools that mainly support one bucket. Error tracking, monitoring, backups, and on-call costs often sit under keep-the-lights-on work. A one-off security review may fit better under risk reduction. If a tool supports everything, split the cost in a way the team can explain in one sentence.

After that, pick a target split for the next quarter. Do not chase a perfect ratio. Choose one that matches the stage of the company. A small SaaS product with paying users might land around 50% roadmap, 30% keep-the-lights-on work, and 20% risk reduction. A shaky product with frequent incidents may need a very different split for a quarter or two.

Three questions keep this honest:

• Did hidden support work eat more time than planned?
• Did the team delay cleanup or security work that now feels risky?
• Did roadmap work slip because keep-the-lights-on work kept cutting into the week?

Finally, review the draft with product, finance, and engineering in the same room. Product checks whether roadmap time is enough. Finance checks whether the numbers match payroll and vendor spend. Engineering checks whether the labels match reality. That turns a messy estimate into a budget people can defend.

A realistic example from a small SaaS team

A team of four engineers and one product lead plans the next month after a messy release. Customers like the new feature set, but the release left behind a trail of small bugs, support tickets, and a few shaky areas in the billing flow. On paper, the founder sees one month of salary. The team sees three kinds of work fighting for the same hours.

They start with a real split instead of one big engineering bucket. Two engineers spend much of the first two weeks on support fixes, production issues, and cleanup from the release. One engineer handles planned feature work that sales already promised. The fourth moves between both, because real teams rarely get clean lines.

Then an outside problem hits. A vendor API changes its auth flow and rate limits, and the product starts failing for part of the user base. Nobody asked for that work, but the team still has to do it. That time belongs in keep-the-lights-on work. If the founder files it under feature delivery, the roadmap looks slow for the wrong reason. If the founder ignores it, the budget looks unrealistically small.

A cleaner monthly split might look like this:

• 45% keep-the-lights-on work for support fixes, regressions, release cleanup, and vendor changes
• 35% roadmap work already approved
• 20% risk reduction for testing gaps, security patches, monitoring, and cleanup in weak areas

That last block matters more than it seems. The team reserves it before the month starts, not after something breaks. They use it to add missing tests around the rough release, patch an outdated package with a known security issue, and tighten monitoring on the vendor integration that just caused trouble.

This kind of example helps in planning meetings because each hour has a job. The founder can explain why roadmap output dipped for a month without sounding vague. The team can also show that less feature work did not mean wasted time. The product needed repair, outside changes demanded attention, and a slice of time protected the next release from repeating the same mess.

Mistakes that make the budget hard to defend

A budget gets shaky when every engineering hour sits in the same bucket. Then a security patch, a checkout bug, and a new feature all look identical on paper, even though they solve very different problems.

Calling every bug fix "maintenance" is one of the most common mistakes. A few fixes after release are normal. A steady stream of bugs in billing, login, or reporting points to a quality problem. If you hide that pattern inside routine maintenance, the team keeps paying for symptoms and never names the cause.

Teams also lose trust when they bury cleanup inside feature estimates. A founder approves a dashboard project, but part of the time actually goes to untangling old code, fixing flaky tests, or cleaning up data models. That work may be justified. Hiding it is the problem.

Vendor changes create another gap between plan and reality. Payment tools change APIs. Cloud providers retire services. Apple and Google change store rules. If your budget ignores outside changes, it will look tidy for one meeting and unrealistic the next month.

A full roadmap with no buffer is another easy mistake. Founders often push for certainty, but software does not stay still. Production issues appear. A dependency breaks. One customer migration takes longer than expected. Without room for that, the roadmap turns into a list of promises the team cannot keep.

One giant line item causes trouble too. If the budget says only "engineering support" or "platform work," nobody can ask useful questions. People cannot tell whether the money goes to uptime, debt cleanup, incident prevention, or product fixes. That is how bad arguments start. Each person imagines a different story behind the same number.

A cleaner budget avoids most of this by doing a few basic things well:

• separate quality problems from normal upkeep
• show cleanup as planned work instead of hiding it
• reserve time for vendor and platform changes
• keep a real buffer instead of a perfect roadmap
• split line items so tradeoffs stay visible

When a team does this, reviews get less emotional. The conversation shifts from "Why is engineering so expensive?" to "Which work supports customers, which work grows the product, and which work lowers risk?"

Quick checks before the planning meeting

A budget gets easier to defend when everyone can explain it in plain words. If finance, engineering, and the founder use different labels for the same work, the meeting turns into an argument about opinion instead of a budget.

Start with the buckets. Each one needs a one-sentence definition that a non-technical person can repeat without help. Keep-the-lights-on work keeps the current product running. Roadmap work ships something new for users. Risk reduction lowers the chance of future outages, security issues, or expensive slowdowns.

Then look at the planned tasks one by one. Every task should sit in one bucket only. If a task seems to fit two buckets, the budget is still muddy. Split the task into smaller pieces until the label is obvious.

A quick test helps:

• If the work fixes or supports today's product, count it as keep-the-lights-on work.
• If the work ships something new for users, count it as roadmap.
• If the work lowers future failure or security risk, count it as risk reduction.
• If nobody can classify it quickly, rewrite the task before the meeting.

Leave room for reality. Teams always spend time on urgent fixes, support follow-up, and cleanup after a release. If the plan uses 100% of engineering time on paper, it is already wrong.

The budget sheet should also show two views at once: hours and cash. Hours help engineering discuss capacity. Cash helps founders and finance compare spend with revenue, runway, and hiring plans. You need both.

One more check matters a lot: can engineering show where last quarter's time actually went? Even a rough breakdown is better than guesswork. If the team planned 20% for keep-the-lights-on work but spent 38%, that gap tells a story. Maybe the product needs cleanup. Maybe support load grew. Maybe the roadmap estimate was too optimistic.

A small example makes this clear. A payment bug fix belongs in keep-the-lights-on work. Extra monitoring around failed charges belongs in risk reduction. A new invoicing screen belongs in roadmap. Put those three items in one pile, and the discussion gets messy fast. Separate them, and the budget becomes much easier to defend.

What to do next

Put the split on one page and make it painfully clear. If your team cannot explain where engineering time goes in a few lines, the budget will keep turning into opinion instead of planning.

A simple note works well. List the three buckets, the rough percentage or monthly hours for each one, and one sentence on why each bucket exists. Add two or three current examples, such as incident response, a planned feature, and a security or backup task.

Keep the note short:

1. Write the current split for keep-the-lights-on work, roadmap, and risk reduction.
2. Add real examples from the last month.
3. Mark anything unusual, like a large migration or a reliability issue.
4. Set the date for the next review.

Then review the split every month. Do not wait for quarterly planning if the numbers already look wrong. A product push can eat more roadmap time than expected. An uptime issue can pull engineers into support work for weeks. Small corrections made early are much easier to explain than a big budget surprise later.

The review does not need a heavy process. One founder, one engineering lead, and one page are often enough. If the same argument keeps coming back, the buckets are still too vague or the team is still mixing categories.

That is a good point to get an outside review. A fractional CTO can usually spot where maintenance work is hiding inside feature estimates, or where risk reduction keeps getting postponed until it turns into an outage. Oleg Sotnikov at oleg.is does this kind of work with founders and small teams, and even one clear review can make the next planning meeting far more useful.