Business Case Development and ROI Analysis Questions

Direct answer

On the spreadsheet, buying wins: five-year cost is $400,000 to buy ($200,000 licence plus 5 x $40,000 support) against $475,000 to build ($350,000 plus 5 x $25,000 maintenance). Once I add what neither figure contains (integration, realistic upkeep, delay, lock-in), the gap widens, not closes. I would recommend buying, unless the product is a differentiator (something customers choose us for and competitors lack) that the company wants to own, in which case I would buy now and build only the differentiating layer later.

Step 1: the comparison, with the arithmetic

Cost over five years, in USD. TCO (total cost of ownership) means everything it costs to own the thing over its life. PV is present value at an 8% discount rate (illustrative), where each year's cost is divided by 1.08 to the power of its year, to reflect that later money is worth less. NPV (net present value) is the PV of everything a choice brings in minus the PV of everything it costs; both options here deliver the same capability, so I compare PV of cost and the lower one has the better NPV.

Build costs $150,000 more up front and saves only $15,000 a year, so it takes 150,000 / 15,000 = 10 years (undiscounted) to catch up. Inside a five-year horizon it never does. Over a seven-year life the same two rows give:

Build is $71,904 worse in today's money ($480,159 minus $408,255), and the payback on the extra spend (10 years) does not occur within seven years.

Step 2: what the spreadsheet misses

Adjusted with the first three rows (illustrative), five-year totals become $471,025 to buy and $775,000 to build (present values $425,179 versus $689,380). The recommendation is the same, with a much larger margin.

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

R = 0.08
buy   = [200_000] + [40_000] * 5
build = [350_000] + [25_000] * 5
print(f"Spreadsheet, 5 yrs undiscounted: buy {sum(buy):,}  build {sum(build):,}")
print(f"Spreadsheet, 5 yrs PV at 8%:     buy {npv(R, buy):,.0f}  build {npv(R, build):,.0f}")
print(f"Undiscounted break-even year for build: {(350_000 - 200_000) / (40_000 - 25_000):.0f}")
print(f"7 yrs PV at 8%: buy {npv(R, [200_000] + [40_000] * 7):,.0f}  build {npv(R, [350_000] + [25_000] * 7):,.0f}")

# Adjusted for what the quote and the first estimate leave out (all illustrative)
buy_adj   = [200_000 + 50_000] + [40_000 * 1.05 ** (t - 1) for t in range(1, 6)]   # +50k integration, support +5%/yr
build_adj = [350_000] + [25_000 + 60_000] * 5                                       # +60k/yr patching, upgrades, on-call
print(f"Adjusted, 5 yrs undiscounted: buy {sum(buy_adj):,.0f}  build {sum(build_adj):,.0f}")
print(f"Adjusted, 5 yrs PV at 8%:     buy {npv(R, buy_adj):,.0f}  build {npv(R, build_adj):,.0f}")

# Same method on other shapes
build_fraud = 450_000 + 3 * 90_000
print(f"Fraud scoring: build 3-yr cost {build_fraud:,}; vendor at 0.04 per transaction breaks even at {build_fraud / (0.04 * 3):,.0f} transactions a year")
print(f"Database 3 yrs: managed {4_000 * 36:,}  self-managed {2_200 * 36 + 3 * 40_000:,}")
print(f"Five point tools vs one platform, 3 yrs: current {3 * 5 * 90_000:,}  platform {500_000 + 3 * 300_000:,}  payback {500_000 / (5 * 90_000 - 300_000):.2f} yrs")

Output:

Spreadsheet, 5 yrs undiscounted: buy 400,000  build 475,000
Spreadsheet, 5 yrs PV at 8%:     buy 359,708  build 449,818
Undiscounted break-even year for build: 10
7 yrs PV at 8%: buy 408,255  build 480,159
Adjusted, 5 yrs undiscounted: buy 471,025  build 775,000
Adjusted, 5 yrs PV at 8%:     buy 425,179  build 689,380
Fraud scoring: build 3-yr cost 720,000; vendor at 0.04 per transaction breaks even at 6,000,000 transactions a year
Database 3 yrs: managed 144,000  self-managed 199,200
Five point tools vs one platform, 3 yrs: current 1,350,000  platform 1,400,000  payback 3.33 yrs

Step 3: the same method on other build-versus-buy shapes

The same two steps apply to other decisions; here are shorter sketches.

• BI reporting worksheet. One column per option, rows for development, maintenance, integration, licences, training and vendor risk, with a final row for 7-year PV, payback of the extra spend, and a confidence label per row. Filled in with illustrative numbers:

• Fraud detection, per-transaction fee. Build is $450,000 plus $90,000 a year for 3 years = $720,000. A vendor at $0.04 per transaction breaks even at $720,000 / ($0.04 x 3) = 6,000,000 transactions a year. Below that volume buy; above it build starts to pay.
• Managed versus self-managed database, 3 years. Managed is $4,000 x 36 = $144,000. Self-managed is $2,200 x 36 = $79,200 plus a quarter of an engineer at $160,000 loaded for 3 years ($120,000) = $199,200. Managed wins unless you already have spare database expertise.
• SaaS versus self-hosted under uncertain demand. SaaS (software as a service: subscription software the vendor runs for you) cost rises with usage; self-hosted (you run it yourself) is mostly fixed. The break-even demand is where the two lines cross. Illustrative numbers: SaaS at $30 per seat per month is $360 per seat a year; self-hosted is a fixed $150,000 a year for servers and a share of an engineer. They cross at $150,000 / $360 = 416.7 seats, so below 417 seats SaaS is cheaper and above it self-hosted is. Where demand is uncertain, I favour SaaS because it can be exited if demand is lower, and I put the switching cost into the build side as a one-off.
• Five point tools onto one platform, 3 years. Today: five tools at $90,000 = $450,000 a year, so $1,350,000. Platform: $500,000 transition plus $300,000 a year = $1,400,000. Savings of $150,000 a year repay the transition in 500,000 / 150,000 = 3.33 years, so three years is not enough and the case depends on sourcing risk (one vendor instead of five) and reduced integration effort.

Recommendation and trade-offs

Buy. The numbers favour it at every horizon here, the build advantage requires a ten-year horizon, and the build side carries the larger unpriced risks (delay, key-person, upkeep). What would flip it: the capability is part of what customers pay us for (differentiation), the vendor's price or terms are likely to worsen sharply, data residency (rules on which country the data may be stored in) or integration rules rule the product out, or our volume grows far enough to cross a per-unit break-even like the fraud example. Sensitivity: the result is most sensitive to the build maintenance estimate. If it truly stays at $25,000 and integration is free, buying is still $75,000 cheaper over five years.

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

A one-page summary for a decision-maker puts the ask first, then proves it is worth funding in the order a sceptical reader asks: why now, what you get, what it returns, what must be true, how it can fail, and when money is released. I use eight sections: 1) the ask, 2) the problem and why now, 3) the proposal, 4) headline financials, 5) key assumptions, 6) sensitivity (low, base, high), 7) risks and mitigations, 8) plan, headcount and decision gates. Below is the page itself, with realistic (illustrative) numbers, and then the reasoning.

(Terms: a tranche is one instalment of a funding amount; a gate is a review where the next instalment is released or refused; to decommission is to switch off and remove; contingency is money held back for overruns; fully loaded cost includes salary, benefits and overhead; run cost is the ongoing cost of operating the thing once built. The page itself, sections 1 to 4, is the core: a CFO reads the ask, the problem, the proposal and the headline numbers first. Everything after it supports those.)

The page (a faithful excerpt)

Order-to-cash data platform: approval requested for $1.5M

1. The ask. Approve $1.5M, released in three $500,000 tranches (at kickoff, at a month-4 gate, at a month-8 gate), to retire the on-premises data warehouse and automate monthly reporting. Decision needed by 30 November so the legacy support contract is not renewed.
2. Problem and why now. Reporting takes 12 analysts about 6 hours a week each in manual spreadsheet work, and the warehouse costs $480,000 a year to run. The support contract renews on 31 January for another year.
3. Proposal. Move to a managed cloud data platform (cloud-hosted storage and query service for analytics), migrate the 40 reports in use, and decommission the old warehouse within 12 months.
4. Headline financials. One-time cost $1.5M. New run cost $20,000 a month ($240,000 a year) against $40,000 a month now. Base benefits at full rate $700,000 a year. Payback (time for cumulative benefit to recover the cost) 2.74 years. Five-year NPV (net present value at 10% discount rate) $771,733.
5. Key assumptions (source, confidence):
   | Assumption | Value | Source | Confidence |
   |---|---|---|---|
   | Legacy run cost retired | $240,000 a year net | Contract and finance actuals | High |
   | Analyst time redeployed | $110,000 a year | 12 analysts x 6 hours x 46 weeks x $65 = $215,280 of time freed. Only half is counted, because only about half of freed time is assumed to be moved onto other useful work: $215,280 x 50% = $107,640, rounded to $110,000 | Medium |
   | Margin from faster pricing decisions | $350,000 a year | Pilot on one product line | Low |
   | Year-one benefit | 40% of full rate | Migration plan | Medium |
6. Sensitivity. Low $450,000 a year: NPV -$39,600, payback 3.93 years. Base $700,000: $771,733, 2.74 years. High $900,000: $1,420,799, 2.27 years.
7. Risks and mitigations. Migration overruns (fixed-price milestones with the partner, $100,000 contingency, gate at month 4). Low adoption by analysts (named champions in each team, training in the budget). Poor source data quality (profiling in month 1, before tranche 2). Vendor lock-in (open data formats, exit clause).
8. Plan and gates. Month 4: first five reports live, tranche 2 only if run cost is at or below $20,000 a month in trial. Month 8: 25 reports live. Month 12: legacy switched off. Team: 6 people for 12 months at $100,000 fully loaded each ($600,000).

Cost split: $700,000 platform and migration partner, $600,000 team, $100,000 training and change management, $100,000 contingency = $1.5M.

The numbers behind the page

The code computes the three scenarios and a check on the cost split. The model treats the $1.5M as spent at the start and counts benefits from year 1 at 40% of full rate, then 100% for years 2 to 5. By hand, the base case: year 1 benefit is 40% x $700,000 = $280,000; years 2 to 5 are $700,000 each. Cumulative cash after year 1 is -$1,500,000 + $280,000 = -$1,220,000, after year 2 it is -$520,000, and after year 3 it is +$180,000. Payback is therefore in year 3, and the code interpolates inside that year: 2 full years + $520,000 / $700,000 = 2.74 years. The NPV discounts each year's benefit at 10% (year 1 by 1.10, year 2 by 1.21, and so on) and subtracts the $1.5M: -1,500,000 + 254,545 + 2,017,183 = about $771,700, which the code prints as $771,733 using unrounded factors. The base case benefits are $240,000 + $110,000 + $350,000 = $700,000; low is $240,000 + $60,000 + $150,000 = $450,000; high is $240,000 + $160,000 + $500,000 = $900,000. The second half of the code belongs to a separate, short example at the end of this answer (an executive summary for paying a higher unit price to a supplier); it does not affect the platform numbers.

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

COST = 1_500_000
def scenario(steady):
    flows = [-COST] + [steady * (0.4 if t == 1 else 1.0) for t in range(1, 6)]   # year 1 at 40%
    cum, payback = 0, None
    for t, f in enumerate(flows):
        prev, cum = cum, cum + f
        if payback is None and t > 0 and cum >= 0:
            payback = (t - 1) + (-prev / f)
    return npv(0.10, flows), payback

for name, steady in (("Low", 450_000), ("Base", 700_000), ("High", 900_000)):
    v, pb = scenario(steady)
    print(f"{name:4s} steady ${steady:,}/yr  5-yr NPV ${v:>10,.0f}  payback {pb:.2f} years")
print("Base mix:", 240_000 + 110_000 + 350_000, " Low mix:", 240_000 + 60_000 + 150_000,
      " High mix:", 240_000 + 160_000 + 500_000)
print("Cost mix:", 700_000 + 600_000 + 100_000 + 100_000)

units, old_price, new_price = 50_000, 12.00, 12.60
extra_price = units * (new_price - old_price)
defects = units * (0.02 - 0.005) * 45                    # 2.0% -> 0.5% defective, $45 each
stock = units / 52 * 3 * new_price * 0.20                # 3 fewer weeks of stock, 20% carrying cost
print(f"Price +${extra_price:,.0f}; defects saved ${defects:,.0f}; inventory saved ${stock:,.0f}; "
      f"net ${defects + stock - extra_price:,.0f} a year")
weak = units * (0.02 - 0.015) * 45                        # defects only fall to 1.5%
print(f"If defects only reach 1.5%: net ${weak + stock - extra_price:,.0f} a year")

Output:

Low  steady $450,000/yr  5-yr NPV $   -39,600  payback 3.93 years
Base steady $700,000/yr  5-yr NPV $   771,733  payback 2.74 years
High steady $900,000/yr  5-yr NPV $ 1,420,799  payback 2.27 years
Base mix: 700000  Low mix: 450000  High mix: 900000
Cost mix: 1500000
Price +$30,000; defects saved $33,750; inventory saved $7,269; net $11,019 a year
If defects only reach 1.5%: net $-11,481 a year

Why this order and these choices

• The ask comes first because a CFO decides on it; everything after is evidence for or against it.
• The low case is shown, not hidden: it roughly breaks even over five years (-$39,600). Honesty here buys credibility for the base case and justifies the tranches, because tranches two and three are tied to measured milestones.
• Confidence labels show the reader that the $350,000 benefit is the weakest number, and that is why sensitivity follows.
• A visual per section: a one-bar-per-driver chart in section 6, a cumulative cash line with the payback point in section 4, a timeline with gates in section 8.

The same page, cut for other asks

• One slide for the CFO (chief financial officer), with a two-to-three sentence ask: "We request $1.5M, released in three tranches of $500,000 against gates in months 4 and 8, to retire a $480,000-a-year legacy warehouse and automate reporting. The base case pays back in 2.7 years with a five-year NPV of $772,000; the low case roughly breaks even (-$40,000), which is why money is tied to milestones."
• Cloud data-lake migration summary: lead with four numbers: one-time cost $1.5M, monthly run cost $20,000 (against $40,000 now), quantified benefits $700,000 a year, payback 2.74 years.
• Analytics-roadmap funding page needing headcount: add the team table: 6 people (2 data engineers, 1 architect, 1 analytics engineer, 1 product manager, 1 change lead) for 12 months, 6 x $100,000 = $600,000, with a roll-off date (the date a person leaves the project) for each role.
• Eight-slide deck: one slide per section above, in the same order.
• One-page ROI model: sections 4, 5 and 6 on one sheet, with the low, base and high columns side by side.

A second, separate example: an executive summary for paying a higher unit price (shorter lead time, fewer defects)

(The same one-page logic applied to a supplier decision; unrelated to the data platform above.) Carrying cost is the yearly cost of holding stock, here 20% of its value. Service credits are contractual refunds the supplier pays when it misses an agreed lead time or defect rate. Illustrative: 50,000 units a year. Price rises from $12.00 to $12.60 (+5%), costing $30,000 a year more. Defects fall from 2.0% to 0.5%: 750 fewer defective units at $45 each in rework and returns = $33,750. Lead time falls from 6 to 3 weeks: three fewer weeks of stock, 50,000 / 52 x 3 = 2,885 units x $12.60 x 20% carrying cost = $7,269. Net: $33,750 + $7,269 - $30,000 = $11,019 a year in favour. Recommendation: accept the higher price, but only with the lead time and defect rate written into the contract with service credits. The margin is thin: if defects only fall to 1.5%, the net is -$11,481 a year, so the defect commitment is the term that matters.

Pitfalls

Page overload (everything above fits on one page only if the assumptions table has four rows, not 20); burying the ask; presenting a single scenario; vague benefits with no owner.

Direct answer

I would convert the six weeks into gross-margin dollars of extra in-season sales, not into revenue, and then discount that figure three ways: for the ramp (new products do not sell at full pace in their first weeks), for incrementality (some of the sales would have closed later in the season anyway), and for confidence that the six weeks are real (confidence is not a separate multiplier in the code; it is expressed by the spread between the conservative, base and optimistic cases, with the conservative case carrying the doubt). Here "pipeline" in "delivery pipeline" always means the build-and-release automation that ships the product, and "sales pipeline" means deals in progress. On the illustrative inputs below that gives about USD 50,000 (conservative), USD 126,000 (base) and USD 235,000 (optimistic), and I would present the conservative figure as the number the case relies on, with the base as the expected outcome. If missing the seasonal window entirely is a real risk, that is a separate, probability-weighted benefit, and I would show it on its own line.

The bridge from "six weeks sooner" to dollars

Faster delivery is only worth money if it changes something the business can observe. The chain is:

1. Calendar: which weeks does the product actually gain? If the product is sold in a 20-week season and the release moves from week 7 to week 1, the gain is six selling weeks inside the season. If the release would have landed before the season anyway, the benefit is close to zero.
2. Run rate: bookings (the value of signed deals, which is not yet recognised revenue or profit) per week at steady state (the normal selling pace once the product is established) in season, taken from last season's actual sales pipeline (not a forecast).
3. Ramp: new releases sell below steady state at first; I use a share of the steady-state rate.
4. Incrementality: of the sales in those extra weeks, only some are new; the rest are customers who would simply have bought later in the season. A sales-pipeline analysis of how last season's deals timed against the release date gives this share.
5. Margin: only gross margin (revenue less the cost of delivering it) is benefit to the business. Revenue is not profit.
6. Cost of delay: the same chain read backwards: each week of delay costs about the weekly gross-margin dollars above. In the base case below, six weeks are worth USD 126,000, so each week of delay costs about USD 21,000.

Worked example (illustrative inputs: USD 100,000 of weekly bookings in season, 70% gross margin)

WEEKS_GAINED = 6
WEEKLY_BOOKINGS = 100_000   # USD of bookings per week at steady state in season (from last season's pipeline)
GROSS_MARGIN = 0.70         # count margin, not revenue

# conservative / base / optimistic
cases = {
    #                ramp (share of steady-state sales in the extra weeks),
    #                incrementality (share of those sales that would NOT have simply closed later in the season)
    "conservative": dict(ramp=0.40, incremental=0.30),
    "base":         dict(ramp=0.60, incremental=0.50),
    "optimistic":   dict(ramp=0.80, incremental=0.70),
}
print("In-season gain from 6 extra selling weeks (gross-margin dollars):")
for name, c in cases.items():
    bookings = WEEKS_GAINED * WEEKLY_BOOKINGS * c["ramp"] * c["incremental"]
    print(f"  {name:13s} incremental bookings ${bookings:>9,.0f}   margin ${bookings * GROSS_MARGIN:>9,.0f}")

# Cliff case: without the faster pipeline the product misses the season with probability p.
# Then the benefit is p x (whole-season margin), not 6 weeks of sales.
SEASON_WEEKS = 20
season_margin = SEASON_WEEKS * WEEKLY_BOOKINGS * 0.60 * GROSS_MARGIN   # 0.60 = average ramp
for p in (0.10, 0.25):
    print(f"  cliff: P(miss season) {p:.0%} -> expected margin protected ${p * season_margin:,.0f}")

# Cash-timing value alone (pulling the same cash 6 weeks forward) is tiny
cash = 1_000_000
rate = 0.10   # cost of capital: the return the money could earn elsewhere
print(f"Time value of receiving ${cash:,.0f} six weeks sooner at {rate:.0%}: ${cash * rate * WEEKS_GAINED / 52:,.0f}")

Output:

In-season gain from 6 extra selling weeks (gross-margin dollars):
  conservative  incremental bookings $   72,000   margin $   50,400
  base          incremental bookings $  180,000   margin $  126,000
  optimistic    incremental bookings $  336,000   margin $  235,200
  cliff: P(miss season) 10% -> expected margin protected $84,000
  cliff: P(miss season) 25% -> expected margin protected $210,000
Time value of receiving $1,000,000 six weeks sooner at 10%: $11,538

Reading it: in the base case, 6 weeks x USD 100,000 x 0.6 ramp x 0.5 incremental = USD 180,000 of incremental bookings, and at 70% margin USD 126,000. Conservative inputs (0.4 ramp, 0.3 incremental) give USD 50,400; optimistic (0.8 and 0.7) give USD 235,200. The gap between the cases is large because the two factors that vary between cases, ramp and incrementality, multiply (0.4 x 0.3 = 0.12 in the conservative case against 0.8 x 0.7 = 0.56 in the optimistic one, a 4.7-fold spread in the result; margin is held at 70% in all three); of the two, the one I would argue hardest to pin down with data is incrementality.

Two other pieces:

• The cliff case: if there is a real chance that without the faster pipeline the release misses the season altogether, the benefit is that probability times the whole season's margin, because a missed season loses every selling week, not just six, so it is not simply 6 weeks of sales (USD 840,000 at the 0.60 average ramp used in the code, which is 20 weeks x USD 100,000 x 0.60 x 0.70). A 10% chance is worth USD 84,000, a 25% chance USD 210,000. I only use it when someone can point to a concrete past slip.
• Cash timing alone is small: receiving USD 1,000,000 six weeks sooner at a 10% cost of capital (the return the money could earn elsewhere) is worth about USD 11,500. It should not be the headline.

NPS and developer velocity

Net promoter score (NPS, a customer-loyalty survey score) and developer velocity (how fast engineers ship) are real but are proxies, not dollars. I list them as supporting evidence and do not add them to the total. If the sponsor insists on a dollar figure for velocity, I would use only the engineering hours that were redeployed to a named, revenue-bearing project, valued at loaded cost, and I would show that figure separately from the sales benefit so nothing is counted twice.

How conservative I would be

Present three cases and anchor the decision on the conservative one; the investment case should still clear its hurdle (the minimum return the company requires) there. Count only the in-season gain unless the cliff probability can be evidenced. Put one season in the headline and treat later seasons as upside, because next year's release timing depends on other things too, and compare the benefit with the delivery pipeline's full cost over the same period.

Trade-offs and pitfalls

• Counting revenue rather than margin overstates the benefit by roughly the inverse of the margin.
• Assuming every extra week sells at steady-state pace.
• Forgetting that six weeks sooner is only valuable if marketing, sales enablement and support are ready to sell in week one.
• Double counting velocity: the same engineer hours cannot both be a cost saving and the cause of the six weeks.

Direct answer

(Terms: a tranche is one instalment of money, released only when a gate (a pre-agreed review) is passed; a stop rule says in advance what result ends the spend. A reason code is the cancellation reason a customer gives or support records; a cohort comparison compares accounts that use certain capabilities with similar accounts that do not; a renewal-risk score is a model or rule that rates how likely an account is not to renew; gross margin on retained revenue is the share of kept revenue left after the direct cost of serving it. A leading indicator moves early; a lagging one, like churn itself, moves late.)

Do not ask a sceptical CFO (chief financial officer) to believe a 25% headcount increase on the strength of a churn forecast. Make the ask small, testable and tied to a break-even number: "Here is what the churn reduction is worth in dollars, here is the smallest reduction that pays for the people, and I am asking you to release money in three tranches, each unlocked by evidence." The first tranche is cheap enough to approve on judgement and exists to test whether engineering can move churn at all.

Churn here means recurring revenue lost from customers who leave or shrink; ARR (annual recurring revenue) is the yearly subscription revenue base.

What I would say in the room

Me: "The ask is up to ten engineers for twelve months, about $2.2M a year fully staffed, to cut churn. I am not asking you to believe a number I cannot prove. The break-even is a reduction of about 0.7 points of annual churn on the staged plan. Our target is 1.5 points. I am asking for $165,000 now, three engineers for three months, to test whether the lever works. Staged, the twelve months cost about $1.65M, not the full $2.2M, because the other seven engineers only join after the month-3 and month-6 gates (on payroll from month 4 and month 7)."

CFO: "Why do you believe engineering can move churn? Customers leave for price, for the sales relationship, for a hundred reasons."

Me: "Right, so the first thing I will show you is the exit data by reason code for the last twelve months, and a cohort comparison of accounts that use the capabilities we would build against accounts that do not. If the reason codes say price and relationship, I withdraw the request. If they say reliability and missing capability, those are engineering-addressable and I will say which ones."

CFO: "And if the pilot works, you come back for the rest?"

Me: "Yes, against agreed gates. If it does not work, you have spent $165,000, not $2.2M."

What I listen for: whether the CFO objects to the evidence (then I fix the evidence), to the size (then I shrink or split the tranche) or to the alternative use of money (then I compare against it directly).

What I show (the artifacts)

1. Churn diagnosis: lost ARR by reason code, with the engineering-addressable share highlighted.
2. A break-even page: the sizing below, with the churn reduction that pays back the cost.
3. The staging plan: three tranches, each with a gate.
4. The alternatives: (a) reprioritise the current team (cost: the roadmap work you forgo, which I would quantify), (b) hire fewer, (c) use contractors for a fixed scope. A CFO will ask "why not reprioritise?", so the answer must be on the page.

The numbers (illustrative company, every input stated)

Illustrative inputs: ARR $150M, gross margin 75% on retained revenue, 40 engineers today so +25% is 10 hires at $220,000 fully loaded cost per year (salary plus benefits and overhead), hired in the three tranches shown below (3 from month 1, 4 more from month 4, 3 more from month 7, each paid from the month they start), and the churn reduction phasing in linearly over months 7 to 18 (new hires need time to ramp up, which is why benefits start only at month 7). The hires are assumed to be fixed-term or to replace planned hiring after month 12, so only twelve months of cost counts: 3 x 12 + 4 x 9 + 3 x 6 = 90 engineer-months x $18,333 = $1.65M. If all ten were on payroll from month 1 the cost would be the full $2.2M and the break-even higher (about 0.9 points); if they become permanent headcount, add $2.2M a year after month 12 and the break-even rises accordingly. The cost assumption is the first thing the CFO will probe. A note on timing: the second and third tranches are approved at the month-3 and month-6 gates, so those engineers are on payroll from month 4 and month 7, which is how the model counts them.

# Illustrative company: 40 engineers, +25% = 10 hires, $220k fully loaded each per year.
ARR = 150.0          # $M annual recurring revenue today
GM = 0.75            # gross margin on retained revenue
LOADED_K = 220       # $k per engineer per year
HORIZON = 36         # months examined
# Staged hiring: (engineers, first month on payroll). 3 now, 4 more from month 4 (after the month-3 gate), 3 more from month 7 (after the month-6 gate).
COHORTS = [(3, 1), (4, 4), (3, 7)]
per_eng_month = LOADED_K / 1000 / 12          # $M per engineer-month

full_year_cost = 10 * LOADED_K / 1000
print("Annual cost of 10 engineers, $M:", full_year_cost)

def cost_staged():
    # twelve months of cost only: each cohort is paid from its start month through month 12
    return sum(n * (12 - start + 1) * per_eng_month for n, start in COHORTS)

def case(churn_cut):
    # churn_cut: fall in annual churn rate (0.015 = 1.5 points), phased in linearly over months 7-18
    kept_arr, gross_profit = 0.0, 0.0
    for m in range(1, HORIZON + 1):
        share = min(max((m - 6) / 12, 0), 1)          # share of the full cut in force this month
        kept_arr += ARR * churn_cut * share / 12      # ARR kept this month that would have churned
        gross_profit += kept_arr * GM / 12            # profit this month from all ARR kept so far
    return kept_arr, gross_profit

cost = cost_staged()
print(f"Twelve-month cost, staged hiring, $M: {cost:.3f}   (all ten from month 1: {full_year_cost:.3f})")
for cut in (0.005, 0.010, 0.015):
    k, g = case(cut)
    print(f"cut {cut*100:.1f} pts: ARR kept ${k:5.2f}M, gross profit ${g:5.2f}M, net ${g-cost:5.2f}M (net if all ten from month 1: ${g-full_year_cost:5.2f}M)")
_, g1 = case(0.010)
print(f"Break-even cut, staged: {cost / g1:.2f} pts; if all ten from month 1: {full_year_cost / g1:.2f} pts")
print("Tranche 1, 3 engineers for 3 months, $M:", round(3 * LOADED_K / 1000 * 3 / 12, 3))
# hand-trace month 12 for a 1.0-point cut
share = (12 - 6) / 12
k12 = sum(ARR*0.01*min(max((m-6)/12,0),1)/12 for m in range(1,13))
print("month 12 share", share, "kept ARR to month 12", round(k12,4), "profit in month 12", round(k12*GM/12,4))

Output:

Annual cost of 10 engineers, $M: 2.2
Twelve-month cost, staged hiring, $M: 1.650   (all ten from month 1: 2.200)
cut 0.5 pts: ARR kept $ 1.53M, gross profit $ 1.24M, net $-0.41M (net if all ten from month 1: $-0.96M)
cut 1.0 pts: ARR kept $ 3.06M, gross profit $ 2.49M, net $ 0.84M (net if all ten from month 1: $ 0.29M)
cut 1.5 pts: ARR kept $ 4.59M, gross profit $ 3.73M, net $ 2.08M (net if all ten from month 1: $ 1.53M)
Break-even cut, staged: 0.66 pts; if all ten from month 1: 0.88 pts
Tranche 1, 3 engineers for 3 months, $M: 0.165
month 12 share 0.5 kept ARR to month 12 0.2188 profit in month 12 0.0137

Reading it: the twelve months of cost on the staged plan is $1.65M (the $2.2M annual figure applies only if all ten were paid from month 1; that bridge also explains the third figure, the $165,000 first tranche, which is just the first three engineers for three months). Each 1.0 point of churn reduction is worth $2.49M of gross profit within 36 months, so break-even is about 1.65 / 2.49 = 0.66, call it 0.7 points (0.9 if all ten started on day one). To trace the model by hand for a 1.0-point cut: in month 12 the cut is half in force ((12 - 6) / 12 = 0.5), so ARR kept that month is $150M x 1% x 0.5 / 12 = $0.0625M; the running total of ARR kept through month 12 is about $0.219M, and month 12's gross profit is $0.219M x 75% / 12 = about $0.014M. Adding up all 36 months gives the $2.49M. At the 1.5-point target the net is +$2.08M by month 36; at 0.5 points the programme loses $0.41M. The retained ARR keeps earning after month 36, which this view ignores on purpose (conservative), but the model also ignores that retained customers can themselves churn later, which flatters it slightly. Say both.

Staging the ask (count: three tranches, 3 + 4 + 3 = 10 engineers)

Each gate has a stop rule agreed in advance: if the leading indicators have not moved at month 3, we stop and the CFO keeps the rest. Leading indicators matter because actual churn is a lagging measure: with an 18-month payoff window you cannot wait for it.

The smaller internal case: architect time on low-margin but strategic accounts

The same method works at small scale. Suppose I need 8 hours a week of a Solutions Architect for six months on three accounts that earn little today but have strategic value (an expansion path, a reference customer).

• Data: each account's margin today, its expansion pipeline, reference value, and the architect's loaded rate ($120 an hour, illustrative).
• ROI model: cost is 8 hours x 26 weeks = 208 hours x $120 = $24,960. Benefit: if architect involvement lifts the chance of closing a $400,000 expansion from 20% to 35%, the gain is 0.15 x $400,000 = $60,000 of ARR, or $42,000 of gross profit at 70% margin. The lift from 20% to 35% is a judgement and is the assumption to defend.
• Stakeholders: the sales leader who owns the accounts, the architect's manager (who loses capacity), and a finance partner who agrees the margin figures.
• Communication: a one-page ask, a month-3 check on whether the pipeline moved, and a stop rule.

Trade-offs and pitfalls

• Asking for the full 25% with a single big forecast is the common failure: the CFO attacks the forecast, not the idea.
• A churn forecast without a causal link (why will engineering effort change who leaves) is the weakest point; fix it with exit reasons and cohorts.
• Staging has a cost: a slower start and a risk that three engineers are too few to show a signal. If the CFO says three is too few to test anything, I would raise it to five rather than abandon staging.
• What would flip my call: if the engineering-addressable share of lost ARR is so small that even a fully successful fix could not deliver the 0.7-point break-even, I would not make this request at all.