The payback formula
That's it. The hard part isn't the maths. It's being honest about what goes into each number.Payback period (months) = Build cost ÷ (Monthly benefit − Monthly running cost)
What counts as "monthly benefit"
- Hours saved × loaded hourly cost. Use the real cost of an employee hour (salary plus overheads), not just wages. Only count hours that actually get redeployed or avoided, such as overtime you no longer pay or a hire you no longer need.
- Subscriptions replaced. If the new system retires three SaaS tools, their monthly fees are a direct saving.
- Errors avoided. Wrong invoices, missed bookings, stock write-offs. Estimate how many happen a month and what each one costs.
- Revenue captured. Faster quotes, fewer abandoned orders, bookings taken after hours. Be conservative here; this is where business cases get inflated.
What counts as "monthly running cost"
- Hosting and third-party services (SMS, maps, payment fees)
- Maintenance and support. A common planning rule of thumb is 15–20% of the original build cost per year
- Internal time spent managing the system
A worked example
Take a regional delivery business taking bookings by phone and WhatsApp, a situation we unpacked in why phone-based cargo booking costs customers. Three coordinators each spend roughly 12 hours a week taking bookings, confirming drivers, and answering "where's my shipment?" calls.| Item | Monthly value (USD) |
|---|---|
| Coordinator time saved (≈156 hrs × $25 loaded) | $3,900 |
| Tools retired (booking form, SMS tool, spreadsheet add-ons) | $600 |
| Missed bookings recovered (10 × $80 margin) | $800 |
| Total monthly benefit | $5,300 |
| Hosting and services | −$200 |
| Maintenance (18% of build per year ÷ 12) | −$450 |
| Net monthly benefit | $4,650 |

When custom software doesn't pay for itself
Now change the inputs. Say only one person saves four hours a week, no tools get retired, and errors are rare. Monthly benefit drops to around $430; after $650 of running costs, the net is negative. The system never pays back. That's not a failure of the formula. It's the formula doing its job. If your numbers look like that, an off-the-shelf tool or a better process is the right answer, and a good development partner should tell you so.Rules of thumb for a sensible payback period
- Under 12 months: strong case. Build, but keep scope tight.
- 12–24 months: reasonable if the process is core to how you make money and will grow with you.
- Over 24 months: revisit scope, phase the build, or buy instead.
- Never: don't build. Fix the process or use an existing tool.
How to shorten the payback period
- Build the highest-value workflow first. Ship the part that saves the most hours in phase one; the rest can wait. (See MVP vs full product.)
- Resist "just one more feature." Every addition extends payback. Here's what one more feature really costs.
- Retire tools on launch day. Savings only count once the old subscriptions are actually cancelled.
- Measure before and after. Log the baseline now so you can prove the result later.



