ROI: a guide for engineers

by Maurizio Lupo

Software development teams are constantly making investment decisions, whether they realize it or not.

Every sprint, prototype, refactor, migration, integration, or infrastructure upgrade competes for limited engineering capacity. Yet many teams still prioritize work based on intuition, urgency, or stakeholder pressure instead of evaluating the actual return on investment.

Treating software development as capital allocation changes the conversation entirely.

Instead of asking:

“What should we build next?”

You start asking:

“Which investment creates the highest return for the business?”

That shift leads to better prioritization, better tradeoffs, and often fewer wasted initiatives.

Gathering information

Product development is an iterative process when ideas are explored before we commit to implement them, following a process called discovery.

The discovery in product terms is aimed to find 4 big risks: value, usability, feasibility, business viability.

But from the ROI prospective we need to estimate 2 other dimensions: costs and value.

Costs

In software development, costs are typically:

  • engineering salaries
  • infrastructure expenses
  • vendor costs
  • operational maintenance
  • support and maintenance overhead

One common mistake is evaluating only the implementation cost while ignoring future operational expenses. Maintenance costs can easily extend for the lifecycle of the software.

Senior engineers/tech leads should have enough experience to estimate the costs.

Value

The value is measure in future cash flow

That cash flow can come from:

  • increased revenue
  • reduced operational costs
  • improved developer productivity
  • reduced incidents management
  • lower infrastructure spending
  • faster delivery speed

The cash flow should be measured in money by a period of time. And should include the length of the period of time.

Usually you use “money per 1 year” and “number of years”

For new products/features the marketing and sales departments can help answering these questions. They usually keep an eye on the competitors and have an idea about the size of the market and the amount of revenue that a certain feature can bring in.

For innovative products, we have to move into the field of guesswork and recalculate the ROI as soon as figures are updated.

Estimating the length can be a bit weird and often you have to rely on historical data. You have to consider:

  • products / features have a lifecycle. We should aim to understand what is the minimum amount of years, that a specific feature can deliver value before is considered obsolete
  • software has a shelf life. I would assume around 3 to 10 years (it may vary depending on your company). You can consider that your software can be written off and rewritten after this period

You have to consider that these are just estimates and it is better being conservative with those and recalculate the ROI as soon as we get fresh data.

Evaluation of the Return of investment

Once we have enough information, the question becomes:

“Is this investment actually (still) worth making?”

To answer that, we can calculate 2 useful index: the payback period and Net Present Value (NPV).

Payback Period

The payback period answers a simple question:

“How long does it take for the investment to pay for itself?”

Shorter payback periods reduce risk because assumptions are generally more reliable in the near term than over many years.

A project with a 6-month payback is fundamentally different from one requiring 5 years before generating value.

The longer the timeline, the more likely assumptions become invalid.

How to calculate it:

const return_by_year = 1300 // I expect 1300 per year as a return 
const investment = 3000 // how much I am investing

const payback_years = investment / return_by_year // 2.31 years

Net Present Value (NPV)

NPV measures the total value created by the investment after accounting for the hurdle rate.

The hurdle rate is the minimum acceptable annual return required to justify the investment. Every cash investment is always competing with other investments. Why would you take a risk for a return of 1% if you can just buy a state bond (for example) and get a safer 4% in return?

In simple terms a negative NPV means that the investment does not justify the capital spent.

How to calculate it:

const hurdle_rate = 0.08 // hurdle rate (8% in the example)
const return_by_year = 1300 // I expect 1300 per year as a return 
const number_of_years = 3 // the product is written off after 3 years
const investment = 3000 // how much I am investing

let pv = 0
for (let year = 1; year <= number_of_years; number_of_years ++) {
  pv += return_by_year / Math.pow(1 + hurdle_rate, year)
}

const npv = pv - investment // 350

How to prioritise

Investment with a negative NPV have questionable ROI, and should be discarded.

The best opportunities usually have:

  • short payback periods
  • positive NPV

These initiatives create value quickly while carrying lower uncertainty.

Investment with a long payback period are more tricky:

  • assumptions may change
  • market conditions may shift
  • the software may become obsolete before delivering expected value

These are not automatically bad investments: they are effectively strategic bets that needs to be periodically reevaluated.

Evaluating Technical Debt and Operational Debt

ROI thinking becomes particularly powerful when applied to technical debt and operational debt.

These initiatives are often difficult to prioritize because they rarely generate immediate visible revenue. As a result, organizations tend to postpone them until the pain becomes severe.

Both technical debt and operational debt create ongoing negative cash flow.

The challenge is simply making that cost visible.

Technical Debt as Future Productivity Loss

Technical debt is, by definition, something that slows down future development.

Examples include:

  • fragile architectures
  • poor test coverage
  • outdated dependencies
  • duplicated logic
  • tightly coupled systems
  • unclear ownership boundaries
  • unreliable deployment processes

Every future feature becomes more expensive to build because engineers spend additional time:

  • understanding complexity
  • debugging regressions
  • handling edge cases
  • coordinating changes
  • working around limitations

In financial terms, technical debt behaves like a tax on future development velocity.

The ROI calculation becomes surprisingly straightforward once framed this way.

You estimate:

  • the cost of fixing the debt
  • the expected productivity gains over the software lifetime
  • the reduction in operational incidents or maintenance overhead

The software lifetime matters significantly here. As mentioned earlier many code bases live somewhere between 3 and 10 years but it can vary according to your company.

Considering a shelf life of 7 years, a refactor that improves delivery speed by 10% over 7 years can easily justify a substantial upfront investment.

Conversely, refactoring a product expected to be replaced within 12 months may have negative ROI.

What also matters a lot is an estimate on how much further evolution will be necessary on a codebase. A codebase that is relatively stable and does not require further investments, will benefit less of any investments.

The key insight is that technical debt repayment is not “engineering hygiene.”

It is an investment in future cash flow through improved productivity.

Operational Debt as Ongoing Operational Cost

Operational debt is different, but evaluated in a similar way.

Operational debt emerges when organizations rely on unnecessary manual or semi-manual processes because automation is missing.

Examples include:

  • manual deployments
  • repetitive support tasks
  • spreadsheet-based workflows
  • manual incident recovery
  • ad-hoc reporting
  • repetitive compliance operations
  • human-heavy release coordination

These activities consume engineering and operational capacity.

Unlike one-time implementation costs, operational debt creates recurring expenses every month.

This makes ROI analysis even easier in many cases because the costs are directly measurable.

You can estimate:

  • hours spent manually operating processes
  • operational risks and incident frequency
  • onboarding complexity
  • coordination overhead
  • expected scaling costs as the business grows

Then compare that against the investment required to automate or simplify the process.

Operational debt often produces some of the clearest low-hanging fruit because automation creates immediate and recurring savings.

A deployment automation initiative that saves 8 engineering hours every week may pay for itself within months.

ROI Thinking Improves Engineering Discipline

ROI calculations are precise only in retrospective, when they can’t be used as a tool to take decisions.

It doesn’t mean they are not useful.

Calculate payback period and NPV on initial estimates can help weeding out projects that have no chance to generate a return.

Even better, if ROI is re-evaluated periodically in light of real results, it can be used to adjust the trajectory of the investment, or determine if the project is not working out as expected and need to be shut down.

A prerequisite for this way to operate is having a plan that allow to deliver the value in as short-as-possible iterations. Basing a multi year project on some initial assumption without chance to validate them along the way, is very very risky!

Used this way, it can improve decision-making and help engineering organizations to allocate limited capacity where it creates the most value.

Because in the end, every software development initiative is an investment decision.

Written by

Maurizio Lupo
Maurizio Lupo Senior Engineering Manager