Platform ROI is a J-curve, not a straight line

The most common mistake in a platform business case isn't an inflated number — it's a straight line. Model the savings as "X% of toil removed, starting month one," and the first real board review will ask why month three doesn't look anything like the projection. It won't, because no platform investment behaves that way. Cost is front-loaded, adoption ramps slowly, and the value only shows up once teams actually migrate onto it — which is a J-curve, not a straight line, and pretending otherwise is what gets a platform team's numbers distrusted the first time reality diverges from the deck.

Why the curve dips before it rises

In year one you're paying platform-team salaries, tooling, and the disruption cost of migrating existing services onto new patterns — before very many teams have adopted anything. That's the trough. The model this maps to is exactly the one behind the ROI calculator: you build before anyone can adopt, so year-one adoption is lower almost by construction, and a platform that's still being built has no product yet for teams to actually use.

adoption(year) = plateau − (plateau − y1) × decay^year

An S-curve, not a step function: adoption starts low, closes the gap to its plateau geometrically each year, and only in later years does the platform reach the steady state where most of its value is actually realized. Model adoption as instant and the year-one number will always disappoint whoever approved the budget.

The trap of a single scenario

A model with one number in it — "the platform saves $2M/year" — invites exactly one question: "what if you're wrong?" A model with a scenario band answers that before it's asked. Conservative, expected, and optimistic scenarios should move every assumption together — benefit realized, cost incurred, adoption speed, and disruption during migration all shift as a coherent set, not independently:

• Conservative — less benefit captured, higher cost, slower and rockier adoption.
• Optimistic — more headroom captured, lower cost, faster and smoother adoption.

The point isn't to be pessimistic by default. It's that a defensible model has to show its assumptions can move in a correlated, realistic way — a reviewer who sees the conservative case still pay back in a reasonable window trusts the expected case far more than one who only ever saw a single cheerful projection.

Building vs. buying changes the curve, not just the total

A home-grown platform doesn't just cost differently than a productized one — it changes the shape of the curve. Year-one adoption falls further, because there's no product to adopt until the build finishes. The adoption plateau itself tends to land lower too, because a home-grown platform typically carries more rough edges that cap how much of the org ultimately migrates onto it. Any honest build-vs-buy comparison needs to model both effects — a slower ramp and a lower ceiling — not just compare sticker prices at steady state.

No double-counting, ever

Total waste removed has to be capped as a share of payroll, and each improvement should remove exactly the waste it targets — no compounding multiplier that lets several driver categories claim credit for the same recovered hour. A model that lets faster deploys, fewer incidents, and reduced toil all independently multiply the same underlying hours will always output a number too large to survive a second look. The guardrail should only ever push the total down, never let a stack of optimistic assumptions amplify each other into an implausible headline figure.

What actually gets reviewed

Nobody signing a platform investment reads the model. They read one page: the J-curve chart with the trough clearly labeled and dated, the payback period, and the scenario band around it. Everything else — sensitivity analysis, per-driver waste buckets, the terminal value assumptions — belongs in an appendix. The model's job is to be defensible on request, not to be the pitch itself.