Over time, software folks come to appreciate adaptability. Building something once, and having it keep working: elastic, scalable, elegant, serving any which need.
That’s an intuition for the value of platforms and learning. But justifying that intuition in the business context can be difficult.
When we build software, we invest. Time and money spent on this, not the other. So we want to pick good investments. Software with “a good ROI”.
Financial methods can help us value software investments in a way that ties directly business outcomes. But traditional valuation methods underestimate the power of platforms and learning because they can’t capture the value of strategic flexibility and uncertainty management.
In this post, I want to dive into the financial mechanics of software investment to highlight where traditional analysis falls short, and show you how to measure the value of adaptability.
Three types of software investment
Let’s get this out of the way first: A business wants to make money, save money, or do both later. Commercial software exists to serve these goals.
At a macro level, we can think about software investment in three categories:
Features create value now
Build a checkout flow -> people can buy -> number goes up. The path from investment to return is quite direct.
Platforms create future options
Build an SDK -> enable new features -> build some of those features -> number goes up. The value is in the flexibility of future investments.
R&D manages uncertainty
Run a pilot -> learn what works -> make better investments -> number goes up. The value is in discovering good investments.
Most businesses benefit from a healthy mix of these three things.
“Feature factory” gets thrown around like a derogatory term, but actually: Features are solid short-term investments because they make money faster. Making €1 today is better than making €1 tomorrow. Where feature factories go wrong is when they fail to balance that with options in the long term. Going only for quick wins, you’ll miss a better long play.
Part of the problem is that we, in software, struggle to show how platforms and learning create business value. The value of features is easily understood (build this, get that), but the rest is a bit harder to reason about. To do that, we need the right financial tools.
When we’re through, I hope to have shown you that adaptability has value, and with the right inputs, we can put a number to it.
A software portfolio
Consider a (fictional) vacation rental platform. The platform manages bookings for property owners and processes €10M in monthly bookings, earning a 10% commission (€1M monthly, €12M annually).
The team is arguing over product roadmap. They have engineering capacity for a few new projects, but several good ideas are on the table. Each idea promises growth, retention or new opportunities, but resources are limited.
Here’s what they’re considering:
Feature: Instant booking
Let guests book immediately without owner approval, for a higher conversion rate.
Feature: Auto-reply
Pre-written templates for check-in, house rules, and checkout, saving property managers time, improving retention.
Platform: Public booking API
Enable property managers to add booking on their own platforms. Could attract more and larger property managers.
R&D: Dynamic pricing
Test if ML-based pricing can beat simple rules. This could increase revenue, but the feasibility of the idea is unknown.
How should they prioritize the work? We can evaluate the portfolio using progressively strategic financial methods.
A note on inputs
Models are only as good as their inputs. Garbage in = garbage out.
When we look at custom software investment, we are mostly thinking about labor cost and impact to ongoing revenue. In other words, we look at the effort required to build the thing, and the money you could make as a result by selling more of it, keeping users for longer or making it cheaper to deliver.
Software estimation is notoriously hard. Some say we shouldn’t bother trying, and I sometimes agree. We can still use estimates to compare investments, though. Not to predict the final outcome, but to get a sense of which investments are more likely to be good. If the estimates are all wrong, hopefully they’re equally wrong. (Side-note: It’s possible to anticipate estimate uncertainty in the cost model itself.)
Rather than front-loading all these inputs, I’ll try to sprinkle them in as we go along.
Round 1: Return on Investment (ROI)
You know this one. Return on Investment (ROI)measures the efficiency of an investment by looking at the ratio between benefits and costs.
# Benefits: What we expect to earn
benefits = 120
# Costs: What we expect to spend
costs = 100
# ROI: The expected return per unit invested
roi = benefits / costs
> ROI = 1.2An ROI over 1 is good. To make ROI more fair, it’s common to combine it with Total Cost of Ownership (ROI/TCO), where we consider all the costs we can think of to build and run the software.
Let’s put some numbers to the investment ideas at hand. Bear with me as we work these out - it will be handy later!
Instant booking
Benefits: Based on industry benchmarks, we expect this will lead to a 10% higher conversion rate. If we assume that 20% of properties adopt this feature over time, it could lead to ~€240k in added revenue yearly.
Costs: The booking team estimates 10 weeks to implement, our initial labor costs being ~€100k and ongoing support cost of ~€20k yearly.
ROI (year 1): €240k / €120k = 2.0
Auto-reply
Benefits: Exit surveys show that half of churned property managers cite “too much time spent on guest communication”. With auto-reply for guests, we expect to quickly reduce churn amounting to ~€120k in retained value a year.
Costs: The frontend team estimates 4 weeks to implement, our initial labor costs being ~€60k and ongoing support cost of ~€10k a year.
ROI (year 1): €120k / €70k = 1.7
Booking API
Benefits: A public API could attract larger property management companies who want to embed booking on their own sites. Let’s optimistically assume 10 new big customers, generating ~€380k a year. This is pure speculation.
Costs: The platform team estimates 16 weeks to implement, our initial labor costs being ~€180k and ongoing support cost of ~€30k a year.
ROI (year 1): €380k / €210k = 1.8
Dynamic pricing
Benefits: The pilot itself generates no revenue. It tests whether a dynamic pricing system is even feasible.
Costs: The data team estimates 6 weeks to prototype, our labor cost being ~€50k.
ROI (year 1): €0 / €50k = 0.0
ROI Scoreboard
If we rank the projects by ROI goodness, instant booking comes out as a clear winner, public API coming in 2nd. Dynamic pricing isn’t even worth talking about.
End of story? Well, no!
There are several things wrong here:
We are not considering timing factors
Projected benefits for the API are highly speculative
We’re ignoring the strategic value of learning
Round 2: Net Present Value (NPV)
Let’s say you take a contract to build an app. Would you rather get paid before or after the work is done?
Before, right?
If you get paid earlier, you can spend earlier: to pay your bills, re-invest or go grocery shopping. There’s also the element of risk. If you get paid before, you’ll definitely have the money. If you wait till later, maybe the client won’t pay. That makes intuitive sense.
Net Present Value (NPV) helps us compare investment decisions in terms of what they’re worth to us today, factoring in the time value of money by “discounting” future cash flows. The discount rate is set to match your expectations of risk, interest and opportunity cost. The influence of discount on cash flow grows exponentially with time.
# Cash flow: The net in/out cash flow at each timestep
cash = [-100, 10, 20, 40, 80]
# Discount rate: How to “discount” future cash flows
discount = 0.1
# NPV: The sum of discounted cash flows
npv = 0
for t in range(len(cash)):
npv += cash[t] / (1 + discount)**t
> NPV = ~10.3A positive number is good. When we compare investments through the lens of NPV, we are optimising for positive cash flows sooner and negative cash flows later. It also lets us compare investments that play out on different time-scales.
Let’s calculate the NPV for our investment options and see what happens. In these examples I choose a discount rate of 2.5% per quarter, reflecting adoption risk and opportunity cost.
Instant booking
Cash flow: We will be paying for initial labor in the first quarter, then ongoing support. We expect the revenue added to grow slowly thereafter, as users progressively adopt.
NPV (year 1): €17.3k
Auto-reply
Cash flow: Fast 4-week build means we can launch in Q1. Retention benefits kick in quickly, from Q2 onward.
NPV (year 1): €22.8k
Booking API
Cash flow: 16-week build drags into Q2. Customer adoption is slow and uncertain. We assume gradual onboarding starting Q3.
NPV (year 1): €-69.5k
Dynamic pricing
Cash flow: The pilot costs €50k in Q1 but generates no revenue without further investment.
NPV (year 1): €-50k
NPV Scoreboard
Let’s rank the projects by Net Present Value. Now that we account for cash flow timings, priorities have changed!
Auto-reply wins on NPV because it pays back quicker. That’s interesting. The API and R&D projects now look quite dire, both projected at a loss. What we see, is that NPV captures the value of timing but not the value of adaptability.
Round 3: Real Options Analysis (ROA)
Traditional valuation methods assume a static world. But our world isn’t static. When the work is complex and the environment is dynamic, it’s good to be adaptable.
There’s a modern approach that can help us here: Real Options Analysis (ROA), quantifying the value of optionality. To understand how it works, we should start with financial options.
Understanding options
Think of a refundable airline ticket. Assume you paid €100 extra for the ability to cancel. If you get sick or change your plans, you can cancel the ticket and only lose the €100 premium. If you end up using the ticket, you’ll have paid extra for flexibility you didn’t need.
The €100 premium buys you an option: the right to refund the ticket later, when you know more.
Financial options are kind of like that. A financial option is the right (but not obligation) to buy or sell an asset at a pre-agreed price and time. Stock options are one example, often used in tech startups as compensation. Take less salary (that’s the premium), get the option to buy stock at a good price later.
Real options build on this idea. The core insight is that you can think of growth investment opportunities as “call options”. When an investment has options, that adds value, because options let us change our approach in response to new information. We can analyse a business strategy as a series of real options.
Using options in software
Building a platform gives you the option to expandinto new territory later. Running an R&D pilot gives you the option to abandon a big project if its outcome isn’t good. These options have value because they let you invest more when things are looking good and cut your losses when they’re not.
# The cost of learning
learning = 30
# The probability of success (40% chance)
chance = 0.4
# The expected benefits (if the project succeeds)
benefits = 200
# The costs to implement the project
costs = 100
# With option: weighting our success and failure branches
branch_success = benefits - costs
branch_failure = 0
expected_with_option = (-learning
+ chance * branch_success
+ (1 - chance) * branch_failure)
# Without option: commit costs regardless of success
expected_no_option = (-costs
+ chance * benefits)
> With learning: €10k
> Without learning: €-20kThe code above demonstrates the value of the option to abandon. It may seem counterintuitive: learning adds €30k in upfront cost. But without it, you commit €100k regardless of outcome, losing that investment 60% of the time. With learning, you only invest the €100k when the learning validates the idea (40% of the time). The option to abandon the project before full investment creates €30k of expected value.
More broadly, we’re happy to see investments that have:
The option to expand (let’s do more!)
The option to contract (let’s do less…)
The option to switch (let’s do something else instead?)
The option to defer (let’s wait and see…)
The option to abandon (let’s drop it and sell for parts.)
The total value of an investment can then be viewed as the value of its options weighted by the probability that we’ll use them.
There are many ways to model real options, binomial trees being quite common. Think decision trees. The underlying mechanics of these models are a bit complicated, which is probably why it has taken some time for real options to gain traction in corporate finance.
Let’s apply it to our software portfolio. If we call the “static NPV” we calculated earlier sNPV, let’s now determine the “expanded NPV” with real options included and call that eNPV. We’ll focus on the API and R&D since these are investments that have options
Booking API
If we see strong enterprise adoption in Q3, we realize that we have the option to expand by investing an additional €80k in Q3 to build premium enterprise features. This will justify a high-value enterprise tier that could generate €400k in additional Q4 revenue.
In the diagram below, we’re looking at two possible futures. In the first, we build the API and see weak adoption: this gives us the original NPV of €-69.5k. In the second, we see strong adoption and capitalize on that by expanding with premium features, reaping a new NPV of €116.4k driven by enterprise license sales.
Weighing these possible futures by their probabilities, the eNPV flips the API from a loss to a gain through the ability to scale based on market signals.
eNPV (year 1): €23.4k
Dynamic pricing
Finally (!) we can explain the value of the dynamic pricing pilot. It creates an option to abandon before a bigger investment.
We spend €50k in Q1 to see if it works. If the pilot fails (70% risk), we abandon and lose only €50k. If it succeeds (30% chance), we invest €200k in Q2-Q3 to build the full thing, expecting to generate €450k in Q4 from dynamic pricing benefits.
Without a pilot, we would either commit €200k on blind faith (risking a total loss) or miss the opportunity altogether. In other words, the pilot limits the downside while preserving potential upside.
eNPV (year 1): €17.5k
eNPV Scoreboard
Now let’s see how accounting for real options changes our rankings:
Our original ROI winner has moved to the bottom because it doesn’t make money quickly and it doesn’t have strategic options. The API is at the top, because we realized the potential of introducing an enterprise pricing tier.
Making the call
What is the rational next step for our vacation rental platform? As with most things in software, it depends.
If we believe and agree on the assumptions presented, we should build the API first because of its strategic potential. The current revenue looks like it could support that. If the focus is instead on short-term survival, we should probably build the auto-reply feature first.
Are these valuations objective and true? Not really!There’s a bunch of assumptions, expectations and guesses involved here. But as we worked our way up the ladder of strategic valuation methods, we became increasingly explicit about the stakes involved.
At the end of the day, we make our best educated guess. But thinking in NPV and real options, we ground our decision-making in structured thinking about uncertainty, timing and adaptation.
Conclusion
I hope you found this helpful (and not boring). Figuring out how to value new software initiatives is a bit of work, but I invite you to try it.
My hope is that you come away with a clearer sense of the financial value of adaptability. Traditional ROI and NPV undervalue platforms and R&D because they don’t capture optionality. Real options analysis gives you the tools to quantify what engineers intuitively know: building for adaptability has real, measurable value.
Knowing this won’t eliminate uncertainty in decision-making. But it will make your assumptions explicit, tradeoffs visible, and priorities defensible.
Whether you’re advocating for piloting a new idea or weighing features against platforms, you now have financial frameworks that match the complexity of the decisions you’re actually making.
Sources
Here are my primary sources for this post. They have lots more great insights, and this write-up would’ve been way too long if I tried to include them all. I can very much recommend checking them out if this topic interests you!
Kent Beck: Tidy First?
Kent Beck: The Good News Factory
Caesar Wu, Rajkumar Buyya: Cloud Data Centers and Cost Modeling
Timothy A. Luehrman (in HBR): Strategy as a Portfolio of Real Options