roi
Should you build it to save money?
A simple way to decide whether an internal build is a real cost saver or just an expensive distraction.
Chris Tune
Most internal tools get sold with the same sentence: “It will save us money.”
Sometimes that’s true. Sometimes it is a neat technical idea with a weak commercial case behind it. The mistake is usually not in the build itself. The mistake is approving the build before anyone has done the payback math.
The quickest way to make that call is to reduce the conversation to four inputs:
- What is the monthly saving if this works?
- How many developer days will it take?
- What day rate should we use for the team doing the work?
- How long are we willing to wait for breakeven?
When those numbers are visible, most debates disappear.
Engineering ROI
Cost-saving build decision matrix
Tune the assumptions, click a scenario, and see whether the build should be approved, spiked, or parked.
Decision
Approve
Breaks even in about 6 months. The saving is strong enough to justify building now.
How to use the matrix
Pick the monthly saving across the top and the estimated dev effort down the left. Then tune the assumptions above the grid.
The matrix gives you one of three answers:
- Approve: the payback is comfortably inside your breakeven ceiling.
- Spike first: the numbers are plausible, but not strong enough to trust without a short validation exercise.
- Park it: the saving is too small or the build cost is too high for the current assumptions.
This is not meant to be perfect finance. It is a forcing function. It stops low-value builds from hiding behind vague phrases like efficiency, platform leverage, or future flexibility.
What this misses on purpose
This matrix is intentionally blunt. It does not account for strategic upside, risk reduction, customer experience, or dependency removal. Those can all justify a build even when the direct saving is weak.
But if the pitch is specifically cost reduction, then cost reduction should carry the argument. If the numbers do not work, the burden shifts back to the proposer to explain what else makes the work worth doing.
A practical decision rule
Use this sequence:
- If the payback is clearly strong, approve it and move.
- If the payback is borderline, spend two days proving the real saving before funding the full build.
- If the payback is weak, do not rescue the idea with optimism. Park it.
That keeps engineering time pointed at changes that either compound value or recover cost quickly.
If you want help pressure-testing a workflow, integration, or internal tool before you commit build effort, get in touch.