engineering
Is It Worth It? A Scrappy Payback Test for Cost-Saving Engineering Work
A back-of-the-napkin framework for deciding whether a cost-saving change - an optimisation, a refactor, or a service migration - is actually worth your team's time, and why the spike that justifies it has to be a risk analysis too.
Chris Tune
A developer comes to you and says: “I think I can cut our costs. Give me some time to look into it.”
Maybe it’s shaving down an over-provisioned server. Maybe it’s a refactor that stops you burning compute. Or maybe it’s the big one — “we should move off Cosmos DB onto Postgres,” or swap one message bus for a cheaper one, or drop a managed service for something you run yourself.
It all sounds great. It might even be great. But “I think I can save us money” is not the same as “this is worth doing right now,” and the gap between those two sentences is where a lot of engineering time quietly disappears.
I’ve started running every one of these through the same simple test. It’s not sophisticated — no NPV, no discount rates, none of the stuff a finance team would insist on. That’s the point. It’s a heuristic you can run in your head in two minutes, and for small to medium engineering changes, a quick screen is usually exactly what you need before you spend real time investigating.
In practice I use two filters:
- Does it pay back inside the window?
- Is this the best use of engineering time right now?
The first is simple math. The second is judgment. Together they’re enough to kill a lot of bad ideas quickly without turning a small decision into a finance exercise.
Here’s how I think about it.
Put a real cost on the work
The first move is to stop treating dev time as free. It isn’t.
Take what an engineer actually costs and load it up. If someone’s on a salary that works out to around $800 a day, I don’t use $800 — I use something closer to $1,500 a day once you fold in overhead: benefits, tooling, the management time spent on the work, the context-switching cost on everything else they’re not doing. I’m not claiming $1,500 is universally correct. The point is to use a fully loaded rate, not a bare salary rate. A multiplier somewhere between 1.5x and 2x salary is usually defensible enough for this kind of first-pass decision. Pick a number, and then — this is the part people skip — use the same number every time so you’re comparing like with like.
Now any change has a price tag. A “three-day job” isn’t three days; it’s about $4,500. Suddenly the question gets sharper.
Make it pay for itself in a reasonable window
Once you’ve got a cost, you need a saving and a deadline.
My rule: the change should break even within 18 months, and ideally a lot sooner. This is not a full ROI model. It’s a payback-period screen. If the recurring monthly saving doesn’t claw back the build cost inside about a year and a half, it’s probably not worth doing — not because the saving isn’t real, but because eighteen months is a long time in any codebase. The thing you optimised might get rewritten. The traffic pattern might shift. The vendor might change their pricing out from under you. The further out your payback sits, the more likely the saving evaporates before you collect it.
So the calculation is just:
Dev cost ÷ monthly saving = months to break even.
Under 18? Worth a serious look. Way over? Probably not.
A $4,500 change that saves $1,000 a month pays back in under five months — easy yes. The same change saving $200 a month takes nearly two years — probably not, unless something else makes it worthwhile.
The 18-month ceiling is really a risk dial
Here’s the thing I had to figure out the hard way: that 18-month number isn’t a financial fact. It’s a risk tolerance, dressed up as one.
If your infrastructure is changing fast — early-stage, high-growth, lots of churn in the codebase — tighten it. Six to nine months. You don’t want to bank on a saving that has to survive two years of upheaval to pay off.
If you’re sitting on stable, boring, load-bearing infrastructure that isn’t going anywhere, you can stretch toward 18 months or even beyond, because you’ve got real confidence the saving will still be there to collect.
So adjust the ceiling to match how much you trust your own six-month-from-now roadmap. The shakier that trust, the shorter the window. If I were working in a fast-moving startup environment, I’d usually want payback in six to nine months. On stable, boring infrastructure with a long lifespan, I’d be more comfortable stretching toward eighteen.
The bigger the change, the more the math leaves out
This is where I want to be careful, because the formula above is genuinely useful but it is also genuinely naive — and the naivety gets dangerous as the change gets bigger.
Trimming a server is low-risk. The cost is the cost, the saving is the saving, and not much else moves. But a migration — Cosmos DB to Postgres, one service bus to another, a managed service to a self-hosted one — carries a whole category of cost the break-even screen simply doesn’t see.
That’s why I treat the math as the first gate, not the whole decision. First ask whether the saving is even large enough to justify interest. Then ask what it costs, operationally and organisationally, to get there.
On a migration, the second gate includes things like:
- Migration risk. Moving data and rewiring code is where outages, data loss, and silent corruption live. The blast radius of getting it wrong dwarfs the monthly saving you were chasing.
- Dual-running. You rarely flip a switch. For weeks or months you run both systems side by side during cutover — paying for both, and maintaining both.
- The learning curve. Your team knows the old thing. They don’t yet know the new one. Velocity dips, and early code on the new platform is the code most likely to be wrong.
- Feature parity gaps. The cheaper option is cheaper for a reason. Cosmos gives you turnkey global distribution and elastic scale; Postgres makes you build or buy those. “Cheaper per month” can quietly mean “and now we own problems the vendor used to solve for us.”
- Lock-in, in both directions. You’re leaving one set of constraints and adopting another. Worth knowing what you’re signing up for before, not after.
- The lifespan of the code. A saving only counts if the system is still around to collect it. Migrating something you’ll deprecate in a year is effort spent to save money you’ll never see.
- Security and compliance surface. A new datastore or transport is a new thing to secure, audit, and reason about. Different defaults, different failure modes, different attack surface.
I’m deliberately not trying to fold these into the initial payback calculation. The moment you start assigning dollar figures to “migration risk” you’ve turned a two-minute gut-check into a week-long spreadsheet exercise, and you’ve lost the whole point of the heuristic. The math stays simple. These stay as a second checklist next to it — the things that can override a “yes” the math handed you, or occasionally rescue a “no.”
When you don’t know the saving yet — spike, and make it a risk analysis
Most of the time the honest answer to “how much will this save?” is “not sure.” That’s fine. That’s what a spike is for.
But time-box it hard. Give it two days, maximum — and for anything bigger than a trivial fix, point it at two questions, not one:
- How much will this save per month, and how confident are we in that number?
- What does it actually cost and risk to get there — and what do we own afterward that we don’t own today?
That second question is the part people skip, and it’s the one that matters most on a migration. The spike isn’t just a savings estimate; it’s a risk analysis. By the time it’s done you should be able to speak to:
- Feature parity — what does the new option not do that the current one does, and what will we build or buy to close the gap?
- Security and compliance — what changes about our attack surface, our audit story, our data handling?
- Lifespan — is this system going to be around long enough for the saving to land?
- Cutover risk and dual-running — how do we migrate without an outage, and how long are we paying for both?
The spike is still not the fix. It’s not “start migrating and see how far you get.” It’s a costed, deliberate investigation whose job is to turn a guess into a number and a risk picture you can actually weigh. If two days isn’t enough to even estimate the saving and sketch the risks, that tells you something too — the change isn’t well-understood enough to safely commit real effort to yet.
A two-day spike is cheap insurance. It either green-lights a genuinely good change or kills a bad one before you’ve sunk a fortnight — or a quarter — into it. Both outcomes are wins.
Don’t forget the question the math hides
The break-even test is good at one thing: killing obviously bad ideas quickly. But it has a blind spot, and it’s a big one.
It looks at the change in isolation. A refactor that breaks even in twelve months looks fine on its own — but if those same engineers could instead ship a feature that brings in new revenue, or fix the reliability issue that’s quietly losing you customers, then the cost saving is the wrong thing to work on, even though it passed the test.
So I run two filters, not one:
- Does it break even inside the ceiling? (The math.)
- Is this genuinely the best use of this person’s time right now? (The part the math can’t see.)
The second question is the one most teams forget, and it’s usually the more important of the two.
Try it yourself
I built a small interactive version of this. Drag the sliders for dev time and monthly saving, set your own day rate and break-even ceiling, and it’ll tell you whether to build, spike, or walk away.
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.
Use it as a first-pass screen for small to medium engineering changes. For a migration, run the same math — then put it next to the risk checklist above before you trust the answer. If the calculator says “yes” but the cutover risk, dual-running cost, or feature-parity gaps are ugly, that’s still a no.
Who this is really for
I’ll be honest about where this framework fits. If you’re at a large enterprise with a finance function that models this stuff properly, you probably don’t need my napkin math for the final decision — you’ve got people whose whole job is to get these numbers right.
This is for everyone else: founders, engineering managers, tech leads, staff engineers, and product-minded leads in small and mid-size teams who have to make practical trade-offs without a layer of analysts between them and the decision.
More specifically, it’s for deciding whether a small to medium piece of engineering work is worth doing before you spend real time on it. Not annual planning. Not portfolio management. Not a seven-figure platform rewrite. A bounded piece of work where you need a fast, defensible “yes,” “not yet,” or “go spike it properly.”
The whole value of a heuristic like this is that it’s quick and good enough. It won’t give you a perfect answer. It’ll give you a fast one that’s right often enough to be worth the two minutes — and it’ll stop you sinking a quarter of expensive engineering time into a migration that saves twenty dollars a day and hands you three new problems.
That trade — a little precision for a lot of speed — is exactly the one most teams should be making. Just remember that the bigger the change, the more the things outside the math deserve a seat at the table.