Business Case Development and ROI Analysis Questions

Direct answer

Lay the proposal out as a year-by-year table with one row per cash flow type: one-time build cost (negative, year 0), recurring operating cost (negative, every year it runs), and benefits (positive, only from the year they start). Add a net row and a cumulative row (the running total of the net row). Here the sponsor is the executive who owns the budget and the decision to fund the project. The project "turns positive" in the year the cumulative row crosses zero, which is the payback period (time until the cumulative cash flow returns the investment). Then add a discounted row so finance can see the same crossover in today's money, plus the net present value (NPV), the sum of all flows discounted back to today.

The artifact (illustrative numbers)

Proposal: $300,000 to build in year 0, $60,000 a year to operate from year 1, benefits of $0 in year 1 (the build is being adopted), $150,000 in year 2 while usage ramps (builds up gradually as more people adopt it), and $250,000 a year from year 3. Convention: negatives are outflows and positives are inflows; year 0 is today, other flows are assumed at year end. The discount rate (the yearly percentage by which future money is shrunk to express it in today's value) is 10%, so a flow in year t is divided by 1.10 raised to the power t. Traced: year 2 is 90,000 / 1.10^2 = 90,000 / 1.21 = 74,380; year 3 is 190,000 / 1.331 = 142,750; year 1 is -60,000 / 1.10 = -54,545.

How to read it:

• Trough (the lowest point of the cumulative line): the cumulative low is -$360,000 at the end of year 1. That is the cash the sponsor must be willing to have exposed, and it is bigger than the build cost because operating cost starts before any benefit does.
• Payback: cumulative crosses zero during year 4. Interpolating: 3 + 80,000 / 190,000 = 3.42 years.
• Discounted payback: about 4.06 years, because later money is worth less (4 + 7,643 / 117,975).
• NPV over five years at 10%: +$110,332.

A chart is the best presentation: bars for net flow per year, a line for cumulative, a marker where it crosses zero, and a shaded region for the trough.

Where each cost sits

• One-time (implementation, data migration, training, parallel running, ramp-up productivity dip): year 0, or the year they are incurred. Do not bury them in the recurring row, or the steady state looks falsely cheap.
• Recurring (licences, hosting, support, people to run it): every year from go-live.
• Benefits: only from the year they are realised, using a ramp, not the steady-state figure from day one.

A second example: why the label and horizon matter

A business intelligence (BI) modernisation costs $250,000 in year 0, $40,000 a year to operate, and saves $90,000 a year of labour from year 2. Nets: -250,000, -40,000, then +50,000 a year. Cumulative after year 5 is still -$90,000. It breaks even at 1 + 290,000 / 50,000 = 6.8 years, which is longer than a typical 3 to 5 year approval horizon. Seeing this in a table is exactly the point: a case that "saves $90,000 a year" can still fail a five-year test.

Trade-offs and pitfalls

• Presenting only the steady-state annual benefit and a simple payback hides the delayed start and the ramp.
• Mixing timing assumptions (cash arriving mid-year versus at year end) silently moves payback; state the convention.
• Payback ignores everything after the crossover; NPV captures it but depends on the discount rate, so show both and state the rate.
• Show a downside column (benefits 20% lower or a year later) next to the base case; the delay assumption usually matters more than the benefit size.

Direct answer

Pick a story where you did not win by arguing the numbers were better than they were. The strong version: you were honest that the financial case was uncertain, you brought a different kind of evidence (the strategic thesis, meaning why the company's direction needs it; option value, meaning the worth of being able to decide later with better information; customer pull, meaning customers asking for it), you converted a big yes-or-no decision into a small, reversible first step with a stop rule, and the executive funded the first step. Below is a complete sample story shape. Replace every detail with your own facts; do not borrow the figures, which are illustrative.

Story skeleton (STAR: situation, task, action, result)

Situation. I was a technical product manager (or architect, or engineering manager) on a data platform team. We wanted $600,000 to rebuild an overnight-load data pipeline (data copied in one big batch each night) into a streaming one (data flowing continuously, within seconds). The strategic reason was real: two enterprise customers had said they would not renew without near-real-time data, and a new product line depended on it. But the financial case was weak: the revenue links were indirect and the cost estimate had wide error bars.

Task. Persuade the executive (a vice president of engineering who had been burned by an over-promised rebuild) to fund it without overstating the numbers.

Action. I brought four things instead of a bigger spreadsheet:

1. A plain statement of what we did not know. "The cost could be 30% higher, and I cannot prove the revenue number. Here are the two assumptions that matter most."
2. Evidence of strategic value that was not a forecast: the two customer statements in writing, the renewal dates, and the competitor capability.
3. The cost of waiting versus the cost of being wrong, shown side by side: the renewals at risk against the $600,000.
4. A reversible structure: I asked for $120,000 (20% of the total) for an eight-week spike (a short, time-boxed technical experiment) aimed at the two riskiest assumptions (can the systems we read from announce every change as it happens without losing any; can we hit the latency target, meaning the delay between an event and its appearance in reports), with a pre-agreed stop rule (a condition agreed in advance that ends the work): if either fails, we stop and the executive keeps the other $480,000.

To handle the perceived risk, I did not argue it away. I separated risks into ones we could test cheaply (technical feasibility), ones we could not control (customer decisions) and ones we could cap (spend), and I showed which risks the first stage removed.

What was said, roughly. Executive: "Last rebuild I funded ran 70% over. Why is this different?" Me: "It may not be, and I cannot prove the revenue number. What I can do is limit what you risk before we know. Give me $120,000 and eight weeks to test the two things most likely to sink it. If either test fails by week eight, you stop, and you keep $480,000." Executive: "And if it passes?" Me: "Then you decide on the second stage with measured evidence, not my forecast, and the two customer renewal dates are in writing on this page." The executive then asked for the stop rule to be written into the approval note, and I did that the same day.

Result. The executive funded the first stage. The spike showed that one source system could not emit reliable changes, so we rescoped before spending the remaining $480,000, which avoided the over-run that had worried the executive. The second stage was approved on measured evidence, and the two accounts renewed (together about $1.4M a year of subscription revenue, an illustrative figure). Looking back, I would run the source-system reliability check in week one rather than week five, because it was the test that mattered most. (In your own story, give the real measurable outcome, such as a number you can defend: a renewal, a cost avoided, a date met. If you cannot cite a number, say what the executive could see and decide.)

What to bring to a conversation like this

• A one-page decision, not a model: the ask, the strategic reason, the two or three unknowns, the staged plan.
• Option value: funding a small first step buys the right to decide later with better information.
• Customer or market pull in the customer's own words.
• A named owner and a date for the stop-or-continue decision.

How to tell it well

• Lead with the tension ("the numbers were weak and the strategic case was strong"), not with the project name.
• Say what you personally did (wrote the stop rule, got the customer statements, presented to the executive), not what the team did.
• Include a moment where you changed your own plan because of the executive's concern. It signals that you listen.
• Close with the result and what you would do differently.

Pitfalls

• A story where you overrode the executive's concern ("I pushed until they gave in") reads as poor judgement, not persuasion.
• Inventing precision. A precise ROI (return on investment, the gain as a percentage of the cost) on an uncertain project makes the executive trust you less.
• Having no result. If the project was later cancelled, say so and say what the first stage saved.
• Telling a story about a team's success where your own contribution is vague.

Direct answer

NPV at 8% is about +$8,800, so on a pure present-value test the project just clears the bar. I would not recommend it on financial grounds alone, though: the cushion is 1.7% of the present value of the inflows, the IRR (the discount rate at which NPV is exactly zero) is 8.9%, and at a 10% discount rate NPV turns negative (-$10,500). A higher required return makes later cash flows count for less, and this project's cash arrives late, so it is very sensitive to the rate.

The calculation

Discount each year's inflow by 1.08 raised to the year number, then subtract the $500,000 paid now:

Undiscounted, the project returns $600,000 on $500,000 (cumulative ROI of 20%), which looks comfortable. Discounting reveals that most of that 20% is simply compensation for waiting three years.

The irr function below is a bisection: it guesses a rate halfway between a low and a high bound, checks whether NPV at that guess is still positive (the rate is too low, so raise the lower bound) or negative (too high, so lower the upper bound), and halves the interval 200 times until it homes in on the rate where NPV is zero.

def npv(rate, flows):
    return sum(f / (1 + rate) ** t for t, f in enumerate(flows))

def irr(flows, lo=-0.9, hi=1.0):
    for _ in range(200):
        mid = (lo + hi) / 2
        lo, hi = (mid, hi) if npv(mid, flows) > 0 else (lo, mid)
    return mid

flows = [-500_000, 150_000, 200_000, 250_000]
for r in (0.08, 0.10, 0.12):
    print(f"NPV at {r:.0%}: {npv(r, flows):>11,.2f} USD")
print(f"IRR: {irr(flows):.2%}")

def after_tax(capex, life, salvage, pre_tax_annual, tax, working_capital=0.0):
    """Straight-line depreciation; working capital out at year 0, back at the end; salvage at the end."""
    dep = (capex - salvage) / life
    flows = [-(capex + working_capital)]
    for y in range(1, life + 1):
        cf = (pre_tax_annual - dep) * (1 - tax) + dep
        if y == life:
            cf += salvage + working_capital
        flows.append(cf)
    return flows

# Harder cases (all inputs illustrative), discounted at 8%
a = after_tax(1_500_000, 6, 0, 500_000 - 200_000, 0.25, working_capital=100_000)
b = after_tax(4_000_000, 5, 400_000, 1_300_000, 0.25)
b[1] -= 500_000 * (1 - 0.25)           # year-1 delayed revenue, after tax
print(f"$1.5M project, 6 yrs, 25% tax, WC 100k: NPV {npv(0.08, a):>12,.0f} USD")
print(f"$4M migration, 25% tax, salvage 400k:   NPV {npv(0.08, b):>12,.0f} USD")
ds = [-80_000] + [(6_000 - 2_000) * 12 - 4_000] * 2
print(f"Data-science build, 2 yrs:              NPV {npv(0.08, ds):>12,.0f} USD, simple ROI {(sum(ds[1:]) - 80_000) / 80_000:.0%}")

# Expansion: 3 years, 300k outlay, 400k/yr extra revenue at 35% contribution margin (revenue left after the
# costs of serving it; ramp 50%, 100%, 100% means year 1 delivers half), plus 60k/yr of margin kept by
# lower churn (fewer customers leaving). Cases scale both benefit lines.
def expansion(scale, rate):
    uplift = [400_000 * 0.35 * k for k in (0.5, 1.0, 1.0)]
    flows = [-300_000] + [(u + 60_000) * scale for u in uplift]
    return npv(rate, flows)

for name, scale, rate in (("conservative", 0.6, 0.12), ("base", 1.0, 0.08), ("aggressive", 1.3, 0.08)):
    print(f"Expansion, {name:<12} (benefits x{scale}, rate {rate:.0%}): NPV {expansion(scale, rate):>9,.0f} USD")

# Three more shapes on the same footing (pre-tax, 8%, illustrative inputs)
phased = [-1_600_000, 900_000 - 120_000 - 1_500_000] + [900_000 - 120_000] * 3 + [900_000 - 120_000 + 300_000 + 100_000]
consolidation = [-4_000_000] + [1_800_000] * 5
self_serve = [-600_000, 0, 300_000, 300_000, 300_000]
print(f"Two-region phased capex, replication cost, WC, salvage: NPV {npv(0.08, phased):>10,.0f} USD")
print(f"Vendor consolidation, 4M transition, 1.8M/yr, 5 yrs:   NPV {npv(0.08, consolidation):>10,.0f} USD")
print(f"Self-serve analytics, benefits start year 2:           NPV {npv(0.08, self_serve):>10,.0f} USD")

Output:

NPV at 8%:    8,814.71 USD
NPV at 10%:  -10,518.41 USD
NPV at 12%:  -28,687.59 USD
IRR: 8.90%
$1.5M project, 6 yrs, 25% tax, WC 100k: NPV     -207,905 USD
$4M migration, 25% tax, salvage 400k:   NPV      536,591 USD
Data-science build, 2 yrs:              NPV       -1,536 USD, simple ROI 10%
Expansion, conservative (benefits x0.6, rate 12%): NPV   -49,280 USD
Expansion, base         (benefits x1.0, rate 8%): NPV   150,605 USD
Expansion, aggressive   (benefits x1.3, rate 8%): NPV   285,786 USD
Two-region phased capex, replication cost, WC, salvage: NPV    397,658 USD
Vendor consolidation, 4M transition, 1.8M/yr, 5 yrs:   NPV  3,186,878 USD
Self-serve analytics, benefits start year 2:           NPV    115,860 USD

Recommendation and what a higher rate does

Financially it is a marginal accept. Inflows would only have to come in 1.7% lower in present-value terms (8,815 / 508,815) to erase the NPV, and a forecast of three years of revenue is not accurate to within 1.7%. I would send it back for two things: firmer year 1 and year 2 numbers, and any way to bring the $500,000 or the timing forward. If the project is strategically important I would say so openly rather than let a thin NPV carry the decision. At 10%, NPV is -$10,518; at 12%, -$28,688. The break-even rate is the IRR, 8.90%, so the margin of safety is 0.9 percentage points.

One-paragraph executive summary. "We recommend a conditional approval of the $500,000 project. At our 8% required return the three-year NPV is +$8,800, with an IRR of 8.9% and a cumulative undiscounted return of 20%. The result is within forecasting error: a 10% rate or inflows 2% below plan make it negative. Approval should depend on confirming year 1 revenue of $150,000 before the second tranche of spend."

Harder cases: adding tax, working capital, salvage and different timing

Real projects rarely stop at three untaxed years, and the same method extends by changing the cash-flow line. Depreciation spreads an asset's cost over its life as a yearly accounting expense, and straight-line means equal slices each year. It is not cash leaving the company, but it lowers taxable profit, so it saves tax of depreciation x tax rate (the tax shield). That is why after-tax cash flow = (savings or revenue minus costs minus depreciation) x (1 minus tax rate), plus depreciation added back because it is not a cash cost. Working capital (cash tied up in stock or receivables) is paid at the start and returned at the end. Salvage is what the asset sells for at the end. Opex (operating expenses) are the running costs. All inputs below are illustrative, at 8%.

Tracing the first case: depreciation is $1,500,000 / 6 = $250,000 a year, and pre-tax operating profit is $500,000 - $200,000 = $300,000. After tax: ($300,000 - $250,000) x 0.75 = $37,500, plus $250,000 added back = $287,500 a year. Year 0 is -$1,600,000 (capex plus $100,000 working capital) and year 6 also receives the $100,000 back. Discounting: $287,500 x 4.6229 (six-year annuity factor at 8%) = $1,329,078, plus $100,000 / 1.08^6 = $63,017, less $1,600,000 = -$207,905.

Tracing the second: depreciation is ($4,000,000 - $400,000) / 5 = $720,000; ($1,300,000 - $720,000) x 0.75 = $435,000, plus $720,000 = $1,155,000 a year. The $500,000 of revenue delayed in year 1 is a deduction: year 1 falls by $500,000 x 0.75 = $375,000 to $780,000, and year 5 gains the $400,000 salvage. NPV is $4,611,580 - $347,222 + $272,233 - $4,000,000 = +$536,591.

The data-science case is worth noticing: ROI says 10%, NPV says about break-even, because the benefits arrive across two years and ROI ignores timing. Three more shapes use the same function with their own cash-flow lines (pre-tax, 8%, illustrative inputs, all in the code above): a two-region phased capex over 5 years ($1.5M now and $1.5M in year 1, $120k a year replication cost, $900k a year benefit, $100k working capital, $300k salvage) has flows of -$1.6M in year 0, -$720k in year 1 ($900k - $120k - $1.5M), +$780k in years 2 to 4 and +$1.18M in year 5 (with salvage and working capital back), giving NPV +$397,658; a vendor consolidation with a $4M transition cost and $1.8M a year run-rate savings for 5 years has NPV +$3,186,878; and a $600k self-serve analytics build with $300k a year from year 2 to year 4 has NPV +$115,860, because the late start costs it but does not kill it.

For an expansion with a revenue uplift and a churn effect (churn is customers leaving, so less churn keeps margin), the base flows are the uplift at 35% margin plus $60k: $400,000 x 0.35 x 0.5 + $60,000 = $130,000 in year 1, then $200,000 in years 2 and 3, against a $300,000 outlay, which discounts to $120,370 + $171,468 + $158,766 - $300,000 = about +$150,605 (the sum of the rounded terms differs from the code's figure by $1). Three-year cases with the stated inputs: conservative (benefits at 60% and a 12% rate) NPV -$49,280; base (8%) +$150,605; aggressive (benefits at 130%) +$285,786. The 40% benefit haircut alone already pushes the case below zero (-$29,637 at 8%), and the 12% rate deepens the loss to -$49,280, while the base benefits at 12% still give +$117,866. No single input decides it, which is why I show cases rather than one number.

Pitfalls

• Mixing pre-tax benefits with after-tax costs, or forgetting that working capital comes back at the end.
• Treating a positive NPV as proof. The NPV must be larger than the forecast error.
• Using one discount rate for every project regardless of risk.

Direct answer

Treat the benefit as a curve, not a number. Estimate the full run-rate benefit (what the improvement is worth per month once everyone is using it), multiply it each month by an adoption share that climbs from 0% toward its ceiling, and charge the costs on their real dates, which usually start before any benefit does. Then justify the curve with evidence (pilot data, rollout schedule, comparable launches), show how NPV and payback move when the curve is slower, and track the leading indicators so the ramp can be checked after approval.

Terms used below. Run-rate means the steady monthly amount once everything is fully in use. Loaded hourly cost is what an hour of an employee really costs the company (pay plus benefits, taxes and overhead share). Leading indicators are early measures (for example weekly active users) that move before the money does. NPV (net present value) is the sum of each future cash flow divided by (1 + rate) raised to the number of periods until it arrives, so later money counts for less. The discount rate is that rate (the return you could earn elsewhere, set by finance). IRR (internal rate of return) is the discount rate at which NPV is exactly zero. Payback is the first period in which cumulative cash turns non-negative. A monthly series needs a monthly rate: use (1.10)^(1/12) - 1, not 10% / 12, so twelve months of compounding gives exactly the annual 10%.

How to build the ramp

1. Full run-rate benefit. Hours saved per person x people x loaded hourly cost x the share of saved time that becomes real cash or real extra output. Freed time is only a cash saving if the capacity is redeployed to other paid work, backfilled less (a departing person is replaced by fewer new hires), or sold; say which.
2. Adoption curve = rollout x usage x proficiency. Rollout is the share of teams that have the tool (from the deployment schedule). Usage is the share of those people who use it in a given month. Proficiency is how much of the full gain a typical user gets while still learning (a new user may get half the time saving that an expert gets). For example, 80% rollout x 70% usage x 60% proficiency is 33.6% of the full benefit. Multiply them; each has its own evidence.
3. Anchor points, then interpolate. Pick a few anchors you can defend (end of year 1: 30%, year 2: 65%, year 3: 90%) and interpolate monthly (fill the months in between with evenly spaced steps from one anchor to the next). Anchors are easier for a reviewer to challenge than a formula. An S-shaped curve (slow start, fast middle, flattening) is usually more realistic than a straight line, but a straight line between honest anchors is fine.
4. Costs on their own dates. Upfront spend lands in month 0 and run costs begin immediately; neither waits for adoption.
5. Justify the shape. In order of strength: your own pilot cohort (monthly usage of the first teams), earlier rollouts at your company, then outside benchmarks. Cap the ceiling below 100% (here 90%) because not every role gets full value. State what would make it faster or slower (training, executive mandate, integration with existing tools).

Worked example (illustrative inputs)

There are two examples. Part A is the main one: a monthly 36-month model of a tool whose benefit ramps up by anchors. Part B is a second, simpler yearly example that tests how sensitive a savings ramp is to slower adoption; it uses year-end cash flows, not monthly ones. Hand check for Part A: month 1 adoption is 30% x 1/12 = 2.5%, so benefit is $80,000 x 2.5% = $2,000, less $10,000 to run = -$8,000. Each month is then discounted by (1 + 0.0080)^month, where 0.0080 is the monthly rate (1.10^(1/12) - 1 = 0.797%); the headline NPV is the sum of all 36 of these plus the -$600,000 at month 0.

A tool is worth $80,000 per month at full run-rate, costs $600,000 upfront and $10,000 per month to run, at a 10% annual rate over 36 months.

# Part A: 36 monthly cash flows for a productivity gain that ramps up
full_monthly = 80_000.0   # $/month once every team has adopted
upfront = 600_000.0       # $ spent in month 0
run_cost = 10_000.0       # $/month licences and support
annual_rate = 0.10
r_m = (1 + annual_rate) ** (1 / 12) - 1     # equivalent monthly rate
anchors = {0: 0.0, 12: 0.30, 24: 0.65, 36: 0.90}   # share of full benefit reached

def adoption(m):
    ks = sorted(anchors)
    for a, b in zip(ks, ks[1:]):
        if a <= m <= b:
            return anchors[a] + (anchors[b] - anchors[a]) * (m - a) / (b - a)

def npv(flows, rate):           # flows[0] happens now (t = 0)
    return sum(cf / (1 + rate) ** t for t, cf in enumerate(flows))

def payback_index(flows):       # first period where cumulative cash >= 0
    cum = 0.0
    for t, cf in enumerate(flows):
        cum += cf
        if cum >= 0:
            return t
    return None

ramp = [-upfront] + [full_monthly * adoption(m) - run_cost for m in range(1, 37)]
flat = [-upfront] + [full_monthly * 0.90 - run_cost for m in range(1, 37)]  # day-one 90%
for m in (1, 6, 12, 18, 24, 30, 36):
    print(f"month {m:2d}: adoption {adoption(m):5.1%}  net cash ${ramp[m]:>9,.0f}")
print(f"ramped:   NPV ${npv(ramp, r_m):,.0f}, payback month {payback_index(ramp)}")
print(f"day-one:  NPV ${npv(flat, r_m):,.0f}, payback month {payback_index(flat)}")

# Part B (second example, yearly): five-year linear savings ramp, 10% to 40% of an addressable cost base
# (addressable cost base = the annual cost the tool can actually reduce)
def irr(flows):
    lo, hi = -0.9, 10.0
    for _ in range(200):
        mid = (lo + hi) / 2
        if npv(flows, mid) > 0:
            lo = mid
        else:
            hi = mid
    return mid

base_cost, invest, run_yr, rate = 1_000_000.0, 450_000.0, 50_000.0, 0.10
def case(stretch):                 # stretch 1.0 = plan, 0.8 = 20% slower adoption
    flows = [-invest]
    for t in range(1, 6):
        # savings share rises 7.5 points a year from a 2.5% start: 10%, 17.5%, 25%, ... 40% at stretch 1
        pct = 0.025 + 0.075 * (stretch * t)     # 10% at t=1, 40% at t=5 when stretch=1
        flows.append(base_cost * pct - run_yr)
    return flows
for name, s in (("plan", 1.0), ("20% slower", 0.8)):
    f = case(s)
    # break-even = first year cumulative cash >= 0; discounted break-even = same, but each year's cash
    # is first discounted to today's money
    cum, disc, be, dbe = 0.0, 0.0, None, None
    for t, cf in enumerate(f):
        cum += cf
        disc += cf / (1 + rate) ** t
        if be is None and cum >= 0: be = t
        if dbe is None and disc >= 0: dbe = t
    print(name, [round(x) for x in f])
    print(f"  NPV ${npv(f, rate):,.0f}  IRR {irr(f):.1%}  break-even year {be}  discounted break-even year {dbe}")

Output:

month  1: adoption  2.5%  net cash $   -8,000
month  6: adoption 15.0%  net cash $    2,000
month 12: adoption 30.0%  net cash $   14,000
month 18: adoption 47.5%  net cash $   28,000
month 24: adoption 65.0%  net cash $   42,000
month 30: adoption 77.5%  net cash $   52,000
month 36: adoption 90.0%  net cash $   62,000
ramped:   NPV $228,345, payback month 29
day-one:  NPV $1,333,560, payback month 10
plan [-450000, 50000, 125000, 200000, 275000, 350000]
  NPV $254,174  IRR 25.0%  break-even year 4  discounted break-even year 4
20% slower [-450000, 35000, 95000, 155000, 215000, 275000]
  NPV $94,386  IRR 16.0%  break-even year 4  discounted break-even year 5

Reading it: adoption is only 30% at month 12, so net cash in month 1 is negative and turns positive around month 6. The ramped case gives NPV $228,345 and payback in month 29. A model that assumed 90% of the benefit from month 1 would show NPV $1,333,560 and payback in month 10, overstating NPV by about $1.1M and understating the payback time by 19 months. The ramp, not the headline benefit, is what the approval decision turns on.

Five-year linear ramp. For a savings rate that climbs linearly from 10% of an addressable cost base in year 1 to 40% in year 5 (base $1,000,000 a year, $450,000 upfront, $50,000 a year to run, 10% rate, cash at year end), the savings share is 10%, 17.5%, 25%, 32.5% and 40% of $1,000,000 (the formula 0.025 + 0.075 x t, which is 10% at t = 1 and 40% at t = 5), less $50,000 a year to run, so the cash flows are -$450,000, then $50,000, $125,000, $200,000, $275,000, $350,000. Discounted at 10% these are -$450,000, $45,455, $103,306, $150,263, $187,829 and $217,322, which add to NPV $254,174, IRR is 25.0%, and cumulative cash turns positive in year 4 (-$75,000 at the end of year 3, +$200,000 at the end of year 4). If adoption is 20% slower (the ramp reaches in 5 years only what the plan reaches in 4; the savings share is 8.5%, 14.5%, 20.5%, 26.5% and 32.5%), the savings rates are lower in every year, NPV falls to $94,386 (about 63% lower), IRR to 16.0%, and the discounted break-even moves from year 4 to year 5. The case still clears a 10% rate but with much less cushion, and adoption pace is the assumption it is most sensitive to because the costs are fixed.

Trade-offs and pitfalls

• Ramp the benefit but not the costs: costs start on their real dates, so the early months are negative. Also model the learning dip (productivity can fall slightly during onboarding); a benefit curve that rises smoothly from month 1 and ignores that dip flatters the first year.
• An S-shaped curve is one that starts slowly, speeds up in the middle and flattens near the ceiling. Do not let the ceiling creep: the curve's end point matters as much as its slope.
• Present base, slower and faster ramps together, and name the leading indicator (monthly active users, share of work done in the tool) that tells you in month 6 which one you are on.
• Dividing the annual rate by 12 gives a slightly different (wrong) monthly rate; use the equivalent monthly rate.

Direct answer

I treat build versus buy as two questions asked in order: is this capability a differentiator (something customers choose us for, where owning it is the product), and what does each path cost to own, not just to start. Default to buy for commodity capabilities (payroll, email, standard monitoring). Build only when the capability is core, when no product meets the real requirement, when the economics flip at scale, or when control over data or the roadmap is a business requirement. Partner sits in between and carries its own lock-in (the cost and difficulty of leaving a supplier once you depend on it).

Decision criteria, in the order I apply them

1. Core differentiator or commodity? A recommendation engine for a retailer built on its own data may be core; the HR system is not.
2. Fit. Does a vendor meet at least 80% of the must-haves without heavy customisation? Customised packages become costly forks (private versions of the vendor's product that you must re-apply every upgrade to). The 80% is my own screening rule of thumb, not an industry standard; I tighten it for regulated needs.
3. Time to market (TTM), the time until the capability is live and earning. How many months until value arrives, and what does each month of delay cost?
4. Total cost over 5 years, with the hidden, ongoing build costs: a maintenance backlog, security patching, on-call and hiring and retention of the people who understand the code, integration upkeep, and vendor roadmap risk on the buy side (the vendor can deprecate, reprice or be acquired).
5. Ownership and optionality. Intellectual property (IP), technical debt we inherit (future rework cost left by shortcuts in code we own), and how reversible each choice is; optionality means keeping the freedom to change course later.

How I estimate each: engineering effort from a bottom-up estimate by the team that would do it (add a contingency, commonly 20% to 40% for software of uncertain scope, labelled as a judgement); run cost as the staffing a service of that size needs, at the loaded salary (salary plus benefits and overheads); vendor cost from a quote; delay cost from the forecast contribution per month.

Worked example (illustrative figures, annual end-of-year cash, 10% discount rate)

A capability would bring $600,000 a year of contribution (revenue minus the variable cost of serving it) once live, or $50,000 a month.

How the NPV (net present value: each future cash flow divided by 1.10 for every year of waiting, then added up) is traced. The four discount factors for years 2 to 5 are 1/1.1^2 = 0.8264, 1/1.1^3 = 0.7513, 1/1.1^4 = 0.6830 and 1/1.1^5 = 0.6209, which sum to 2.8817. Buy: -50,000 + 300,000 / 1.1 + 450,000 x 2.8817 = -50,000 + 272,727 + 1,296,761 = $1,519,488. Build: -600,000 + 0 + 330,000 x 2.8817 = -600,000 + 950,958 = $350,958. Both round to the table's figures.

Buy wins by about $1.17M. The delay alone (nine extra months at $50,000) costs $450,000 of contribution before discounting; the rest of the gap comes from the $550,000 higher up-front cost ($600,000 against $50,000) and the $120,000 a year higher running cost ($270,000 against $150,000), which the build option starts paying only once it launches; that is partly offset by build paying no running cost in year 1. Undiscounted, the gap is 450,000 + 550,000 + 480,000 - 150,000 = $1,330,000, which discounts to the $1.17M shown.

When I would build

• Scale flips the economics. If the subscription scales with usage (assume the fee rises in proportion to volume: twice the volume, twice the fee), the break-even is where fees equal the owned cost. Amortise the build (spread the one-off cost evenly over the years it serves) over 5 years: $600,000 / 5 = $120,000, plus $270,000 run = $390,000 a year. The subscription at today's volume is $150,000, so the crossover is at $390,000 / $150,000 = 2.6 times today's volume (ignoring discounting and growth in build run costs).
• The capability is what customers pay for, or the vendor cannot meet a latency, residency (rules on where data must be stored) or regulatory need.
• Partner instead: if a partner takes 20% of revenue, partner cost equals the $270,000 owned run cost when revenue is $270,000 / 0.20 = $1.35M a year. Below that revenue partnering is cheaper to run; it also gives early launch and optionality (we can build later, once volume is proven), at the price of margin and dependency. Side by side with the table above, partner is a running cost of 20% of revenue: at $750,000 of revenue it costs $150,000, equal to buy's subscription, and at $1.35M it equals the $270,000 of build's running cost; below $750,000 it is the cheapest of the three to run.

Pitfalls

Comparing build cost to subscription cost and forgetting the run staff; assuming the build is finished (maintenance never ends); choosing "build" because engineers prefer it; ignoring that switching vendors later costs migration effort. What would change my call: evidence the capability is where we beat competitors, or volume forecasts well beyond 2.6 times.