Choosing Between Maintenance and New Features: A Priority Framework

You’re running an ecommerce business or managing a digital product. Your developer says the checkout flow needs refactoring. Your marketing manager wants a new product recommendation engine. Your budget covers one.

Which do you choose?

If this feels familiar, you’re not alone. Every digital team faces a version of this constantly – fix what you have, or build what you want. Get it wrong in either direction and it costs you. Southwest Airlines famously chose features and cost savings over system maintenance for years, until a 2022 holiday meltdown cancelled 16,700 flights and cost over a billion dollars. But teams that only maintain and never build fall behind just as surely.

The four questions below give you a consistent way to make these calls – whether you’re evaluating a new feature or a maintenance task.

The Framework: Four Questions

Instead of treating every decision as a unique puzzle, run it through these four questions. They work whether you’re evaluating a new feature or a maintenance task – the framing shifts slightly depending on what you’re assessing, but the questions stay the same. For weighing technical debt items specifically against each other, a similar scoring approach works for technical debt prioritisation.

Question 1: What do you gain? The upside case. What changes for the business or customer if this gets done?

Question 2: What do you risk by waiting? The downside case. What’s the cost of not doing this – lost revenue, compounding friction, risk?

Question 3: What’s the real cost? Build time and ongoing maintenance burden.

Question 4: Is this urgent? Is there a deadline, dependency, or closing window that makes timing matter?

Score each one – Significant, Considerable, Moderate, or Minimal – then total them up. Higher scores go first.

Question 1: What do you gain?

Start with the upside. Not the feature spec or the technical improvement – what actually changes for the business or the customer if this gets done?

For a new feature, ask: does this drive revenue, improve retention, reduce friction, or improve the customer experience in a meaningful way? For maintenance work, ask: does fixing this unblock something, remove a recurring cost, or reduce risk in a way that matters?

Score it:

• Significant – direct, measurable business outcome
• Considerable – clear improvement, harder to measure directly
• Moderate – useful but limited in scope or audience
• Minimal – marginal gain, nice to have

Example in practice:

Your publishing platform is considering a ‘look inside’ feature for book previews. The impact case is that customers who preview are more likely to buy – it reduces purchase hesitation and could directly lift conversion. That’s Considerable at minimum, Significant if the data supports it. Meanwhile, increasing test coverage improves confidence in deployments and reduces the risk of regressions – real value, but harder to attach a number to. Moderate to Considerable depending on how fragile the codebase currently is.

Question 2: What do you risk by waiting?

Where question 1 looks at the upside, this one looks at the cost of not acting. What happens if you defer this – does anything compound, deteriorate, or fall further behind?

For a new feature, ask: are customers churning without this, is revenue being left on the table, is a competitor pulling ahead? For maintenance work, ask: is this getting worse over time, is it generating support tickets, is it slowing down everything built on top of it?

Score it:

• Significant – actively losing ground without it
• Considerable – friction or gap that compounds over time
• Moderate – noticeable but tolerable, safe to defer
• Minimal – no real consequence to waiting

Example in practice:

The ‘look inside’ feature doesn’t exist yet, so nothing is actively broken without it – but if competitors offer previews and you don’t, that’s a gap that compounds as customer expectations shift. Considerable. Increased test coverage is a different kind of significance – without it, every deployment carries more risk and regressions take longer to catch. If the codebase is already fragile, that’s Considerable. If deployments are currently stable, it’s Moderate.

Question 3: What’s the real cost?

This is where most people go wrong. They compare quoted development time and think they have their answer. Two weeks for the feature, three weeks for the maintenance task – feature wins.

The real cost includes more than build time:

• Development time – obvious
• Ongoing maintenance burden – every new feature is code you now have to support, update, and keep running

Score it:

• Very low – quick to build, minimal ongoing maintenance, frees up future capacity
• Low – reasonable effort, minor ongoing burden
• Moderate – significant build, some ongoing commitment
• High – expensive to build and/or maintain long term

Example in practice:

A ‘look inside’ feature requires integrating with a file storage system, building a reader interface, and handling publisher permissions. That’s a meaningful build with ongoing maintenance as the platform evolves – Moderate at best. Increasing test coverage has a different cost profile: it takes time upfront but reduces maintenance burden over time. If it prevents one significant regression per quarter, it pays for itself quickly – Low to Very low depending on scope.

Question 4: Is this urgent?

The first three questions tell you how valuable something is. This one tells you whether timing matters.

Urgency is binary. Either there’s a deadline, dependency, or closing window that makes this time-sensitive – or there isn’t. A competitor launching a similar feature next month is urgent. A compliance deadline is urgent. An integration that breaks when a third-party platform updates is urgent. Everything else can be sequenced on merit.

This is deliberately a forcing question. If you find yourself arguing that something is kind of urgent, it isn’t. Urgency means something changes if you don’t act now – not soon, now.

Score it:

• Urgent – hard deadline, dependency, or closing window
• Not urgent – timing is flexible

Example in practice:

The ‘look inside’ feature has no hard deadline – it’s a conversion improvement that’s valuable whenever it ships. Not urgent. Increased test coverage becomes urgent if there’s feature work coming that will touch areas of the codebase that currently have no test coverage – without it, you’re building on an untested foundation. If the next few sprints are in well-covered areas, it can wait.

For the flip side of this question, deciding when something is actually ready to ship rather than when to build it, we’ve written a companion framework for deciding when to ship.

Bringing It Together: The Scorecard

Once you’ve scored all four questions, add them up. Each question scores between 1 and 5, giving a maximum of 20.

Score	Recommendation
14 – 20	Strong case to proceed
10 – 13	Proceed after higher priorities
6 – 9	Low priority
Below 6	Defer

The score doesn’t make the decision for you – it makes your reasoning visible. Two items with the same score can still be sequenced differently based on team capacity or context. But when you’re looking at a backlog of ten things and everyone has an opinion, having a consistent score for each one cuts through the noise.

The real power is in sorting. Score everything, sort by total, and your priorities surface. An item sitting at 7 next to three items at 14 isn’t a judgment on its worth – it just goes later.

When to Override the Framework

Scores are a guide, not a rule. Sometimes the right call sits outside what the numbers say.

Override towards a new feature when:

• You have a narrow market window – a competitor is launching, a seasonal opportunity is closing
• A major customer or contract depends on a specific capability
• You’re validating a completely new business model and speed matters more than certainty

Override towards maintenance when:

• You’re experiencing actual outages or data loss
• Your team is spending more time fixing than building
• You’re about to scale – a major campaign, a new integration, a platform migration

When you override, note why. The value of a framework isn’t that it’s always right – it’s that deviating from it deliberately is better than never having a baseline in the first place.

Used consistently, the scorecard also shows you something about yourself. If you’re regularly overriding towards features, you have a feature bias. If maintenance items keep topping your list but never get done, something else is driving your decisions. The pattern is worth knowing.

What Consistent Use Looks Like

The scorecard doesn’t change how you work – it changes how you decide. Used regularly, here’s what shifts.

After a few months of scoring decisions:

• Priorities are defensible – you can show your working to stakeholders, clients, and your team
• Gut calls get tested – if something feels urgent but scores low, that tension is worth examining
• Patterns emerge – which types of work you systematically over or undervalue
• Conversations get shorter – instead of relitigating priorities every sprint, you have a shared framework to return to

The goal isn’t to score everything perfectly. It’s to be deliberate – to know why you’re doing what you’re doing, and what you’re trading off to do it.

Your next decision

The next time you’re choosing between two competing items, run both through the four questions:

1. What do you gain?
2. What do you risk by waiting?
3. What’s the real cost?
4. Is this urgent?

Score them. Sort them. Make the call.

Need help making these calls for your Rails, Shopify, or React Native application? That’s exactly what we do at MV Studio. We help ecommerce businesses maintain their technical foundations while moving forward with confidence. Get in touch if you’d like to talk through your specific situation.