Custom software pays for itself once the money it saves or earns each year, minus its running costs, adds up to more than the build price. For many growing businesses that takes two to three years, but only when the software removes real labour, replaces rising subscription fees or unlocks revenue. Otherwise, it never does.
That sounds obvious, yet most build-or-buy debates skip the arithmetic. This post gives you a simple formula, a fully worked example and the traps that make projects look better on paper than in practice.
How do you calculate the payback period?
Payback period = build cost ÷ (annual benefit − annual running cost). The answer is the number of years before you are ahead.
Three inputs matter:
- Build cost: the quoted price for the first version, plus your team's time during the project.
- Annual benefit: labour hours saved, subscriptions cancelled, errors avoided and any extra revenue the software makes possible.
- Annual running cost: maintenance (typically 15–25% of the build cost per year), hosting and any third-party usage fees.
If annual benefit is lower than annual running cost, the denominator is negative and there is no payback at all. That is the first thing to check.
What counts as a benefit, and what does not?
Count benefits you can measure or confidently estimate; leave out the ones that only sound good in a meeting. Inflated benefits are the most common reason build cases disappoint.
Benefits you can usually measure:
- Hours saved. Re-keying data, chasing approvals, building reports by hand, searching for files. Multiply hours by the loaded cost of the people doing the work.
- Subscriptions replaced. Only count tools you will actually cancel.
- Errors avoided. Wrong invoices, missed bookings, double-booked staff. Use your own history, not a guess.
- Revenue unlocked. Faster quotes, self-service bookings or a new product. Count this conservatively, because it depends on customers, not just software.
Benefits to treat with care:
- "Better visibility" and "a single source of truth" are real but hard to price. Note them as upside, not as numbers.
- Time saved only becomes money if those hours go to something valuable, or you avoid a hire.
What does a worked example look like?
Here is a hypothetical 25-person services business weighing a custom operations tool against its current SaaS stack. Every number is illustrative, chosen to show the method.
Current situation:
- A SaaS tool at an assumed US$60 per user per month for 25 users: $18,000 a year.
- Six staff each spend about 30 minutes a day copying data between that tool and their accounting system. Over roughly 230 working days, that is 690 hours. At a loaded cost of $35 an hour: $24,150 a year.
Custom option:
- Build cost: $45,000 (within the typical US$15k–50k MVP range).
- Maintenance at 20% of build: $9,000 a year. Hosting: $1,200 a year.
Annual benefit is $18,000 + $24,150 = $42,150. Annual running cost is $10,200. Net annual benefit is $31,950. Payback: $45,000 ÷ $31,950 ≈ 1.4 years, or about 17 months.
| Year | Benefit | Running cost | Net for the year | Cumulative position |
|---|---|---|---|---|
| 0 (build) | — | — | −$45,000 | −$45,000 |
| 1 | $42,150 | $10,200 | $31,950 | −$13,050 |
| 2 | $42,150 | $10,200 | $31,950 | +$18,900 |
| 3 | $42,150 | $10,200 | $31,950 | +$50,850 |
Now stress-test it. Suppose you only capture half the time savings because staff spend some of the freed time on low-value work. Annual benefit drops to $30,075, net benefit to $19,875, and payback stretches to about 2.3 years. If the case still works with half the benefits, it is a robust case. If it only works with every assumption at its best, it is not.
Why does team growth change the answer?
Per-seat pricing scales with headcount, while custom software costs mostly stay flat. That is why build cases often get stronger as a business grows.
Using the same assumed US$60 per user per month:
| Users | Annual SaaS cost | Custom running cost (example above) |
|---|---|---|
| 10 | $7,200 | $10,200 |
| 25 | $18,000 | $10,200 |
| 50 | $36,000 | $10,200 |
| 100 | $72,000 | $10,200 |
At 10 users, SaaS is cheaper to run every year even before you count the build. At 50 users, the running-cost gap alone pays for a build within a couple of years. Real custom costs do rise with heavier usage (more hosting, more support), but far more slowly than seat licences.
For a deeper look at whether a ready-made tool fits, use our custom software vs off-the-shelf SaaS scoring checklist.
What costs do build cases usually forget?
Most optimistic build cases miss the same four costs. Add them before you trust the payback number.
- Maintenance. Roughly 15–25% of the build cost every year, for security updates, dependency upgrades, bug fixes and small changes. Leaving this out flatters every calculation.
- Your team's time. Discovery workshops, feedback on designs, testing and training. Budget a few hours a week from a decision-maker, more around launch.
- Data migration. Cleaning and importing existing records can be a meaningful part of the project.
- Time to value. Benefits do not start on the day you sign. A typical MVP takes 8–16 weeks to build, then weeks more for staff to adopt it. See realistic timelines by project type to factor this in.
When does custom software never pay for itself?
It never pays back when the process is small, unstable or already well served by a cheap product. Honest examples:
- Small teams on cheap tools. Five users on a $30-a-month plan cost $1,800 a year. A $20,000 build with $4,000 a year of maintenance cannot win on cost.
- Processes that keep changing. You will pay to rebuild features every few months.
- Vanity projects. Software built because a competitor has an app, without a clear job for it to do.
- No maintenance budget. Unmaintained software slowly breaks, becomes insecure and ends up replaced.
In these cases, configure a good SaaS product and revisit the question when headcount or complexity grows.
How can you lower the risk of building?
Build the smallest version that captures most of the benefit, then measure before you expand. Payback arrives faster when the first release is lean.
- Target the costliest step first. In the example above, that is the 690 hours of re-keying. An integration alone might capture most of that saving for a fraction of the full build.
- Ask for a fixed price on a clearly defined first phase so the cost side of the formula is known.
- Measure before and after. Record how long the current process takes now, so you can prove the saving later.
- Keep the SaaS tools that work. A hybrid (SaaS core plus a custom layer) often has the shortest payback of all.
CRM is the most common place this decision comes up. Our guide to what a custom CRM costs to build gives typical figures you can plug into the formula. The formula is one input; the full custom software guide for growing businesses covers the rest of the decision, including process and ownership.
Frequently asked questions
What is a good payback period for custom software?
Many owners look for payback within two to three years, because software needs updating over time and business needs shift. A shorter payback gives you more margin for error. If your case only pays back after five years, scope a smaller first phase or reconsider.
How do I estimate hours saved before the software exists?
Time the current process for a week or two. Ask the people doing the work to log how long each repetitive task takes, then multiply out over a year. Their records will be more accurate than a manager's estimate.
Should I include revenue growth in the calculation?
Include it only if you can link it directly to the software, such as online bookings you currently turn away. Keep it separate from cost savings so you can see whether the case works on savings alone.
Is it cheaper to customise a SaaS product than to build?
Often, if the product has good integration options and you only need small changes. Heavy customisation of a SaaS tool can become fragile and expensive, though, because vendor updates may break your changes.
Does the payback formula work for AI projects too?
Yes. Count the hours an AI feature saves and any usage fees it adds, then apply the same formula. Include a person reviewing outputs where mistakes are costly, because that time is part of the running cost.
Want a second opinion on your numbers?
If you have a rough build case, we will happily sanity-check it with you and scope the leanest version worth building. Send us your current tools and the process you want to fix, and we will return a fixed-price quote you can plug into the formula. Examples of our builds are on our work page.