You've got a proposal for custom software sitting on the desk. The scope looks right. The team seems capable. And there's one question you keep turning over at 11pm: will this actually pay for itself?
Fair question, and a better one than most buyers ask. The honest answer is that custom software ROI is easier to estimate than people think, because the gains are mostly things you already pay for today. You just haven't seen them on one page.
This isn't a pitch for building. Sometimes the math says no, and we'll show you what that looks like. By the end you'll have a method you can run on a legal pad, a worked example with clearly made-up numbers, and a feel for which gains are solid and which are wishful thinking.
Why custom software ROI is hard to see
A website at least has a front door you can count. Custom software works in the back, and what it earns is mostly costs that stop happening.
That's the first problem. Savings are quiet. Nobody sends you an invoice that says "four hours of copying numbers between two apps, again." You pay it in payroll, spread across a week, and it never gets its own line.
The second problem is that the cost side is loud. A build has a number on a proposal, and you can see it. The gains live in a dozen small places and take some digging. So the comparison tilts toward "too expensive" before anyone has done the digging.
The fix is to make the quiet costs visible first. Think of four buckets, and count them one at a time:
- Hours your team spends on work the software would do.
- Mistakes that cost you money or goodwill.
- Subscriptions the system would replace.
- Cash that arrives faster.
If you want a faster version, our ROI calculator does a rough pass with a few inputs. The rest of this article is the slower, more honest version that you can defend to a partner or a bank.
Bucket one: hours saved
Start here, because it's usually the biggest and the easiest to measure.
Pick a normal week. Ask each person who touches the process to track, for just that week, the time they spend on three things: re-entering information that already exists somewhere else, hunting for a file or a status, and chasing someone for an answer. Rough minutes on a sticky note are plenty.
Add it up across the team, then multiply:
- Hours per week, across everyone
- times the number of working weeks in a year
- times what an hour of that person actually costs you (pay plus taxes and overhead, not just the wage)
A few honest warnings. First, software rarely removes 100% of a task. If a step takes ten minutes and the system shrinks it to two, count eight. Second, be careful about what the freed hours become. If they turn into billable work or more sales calls, that's real money. If they turn into a calmer afternoon, that's real too, but it's a different kind of value, and you shouldn't promise a bank it will show up on the income statement.
The third warning is the most common one. People count hours that nobody was ever going to get back. If your team works a fixed schedule and the work expands to fill whatever time exists, the savings are theoretical. Only count what you'd actually do something with.
Bucket two: errors avoided
Every manual handoff is a chance for a mistake. A quote that used the old price. An invoice that went to the wrong contact. A job booked twice, or not at all. A client told "yes, that's included" when the file said otherwise.
Each of those has a cost, and usually more than one: the credit you give to apologize, the hours someone spends fixing it, the repeat customer who quietly stops calling. Owners tend to remember the dramatic ones and forget the steady drip.
To count them, think back over the last six months and list the mistakes you can name. Put a rough cost beside each one, including your own time. Then ask the key question: would the system have prevented it? A system that fills in the price from one source of truth prevents the stale-quote error. A system that can't stop a customer from changing their mind doesn't prevent that.
Be conservative here. A good habit is to count only the errors you can name and the ones you're confident the software would stop, and leave out the vague "we'll probably make fewer mistakes" idea. If the number still looks good after you've been stingy, you can trust it.
Bucket three: subscriptions you can drop
This one is the cleanest, because it comes straight off your statements.
Pull three months of card and bank statements and list every software subscription. For each, note the monthly cost and who uses it. Then mark the ones a custom system would actually replace, as opposed to the ones you'd keep. You'll keep email, payroll and probably your accounting. You may drop the project app, the form tool, the scheduling tool, the extra CRM seats.
Two things catch people out. One is annual billing: a tool that looks like a small monthly charge may be a bigger lump once a year, so add it up on a yearly basis. The other is per-seat pricing, where the cost climbs every time you hire. Our piece on SaaS sprawl walks through how to audit the full stack, and it's worth doing before you run any ROI math at all.
Then be fair to the other side. Custom software has running costs of its own: hosting, upkeep and occasional changes. Subtract those. The gain is the subscriptions you drop minus what you now pay to keep the new system healthy.
Bucket four: cash that arrives sooner
This is the bucket owners forget, and for some businesses it matters more than the other three.
Think about how long it takes between finishing work and getting paid. If invoices go out a week late because someone has to assemble them by hand, that's a week of your money sitting somewhere else. If customers pay faster when there's a pay button on the invoice and an automatic reminder, you shorten the gap again.
Faster collection is different from a saving, and it's worth being precise about it. It's a one-time release of cash: you get to hold money you used to wait for. That can matter a lot if cash is tight, because it can stand in for a credit line, but it doesn't repeat every year the way a saved hour does. Count it separately, and don't add it to your annual gains.
If you're curious how this looks in a real system, the dashboard in StackOS, the system that runs our own studio, shows cash, income and money owed in one place, which is exactly the kind of visibility that makes late payments obvious instead of hidden.
A worked example (with made-up numbers)
Time to put it together. The business below is hypothetical. The numbers are invented to show the method. They describe a business like yours, not a client of ours, and they're not a promise about what any project will return.
Picture a twelve-person service company. Quotes, scheduling and invoicing run through four tools plus a shared spreadsheet.
Hours. Six people each lose about four hours a week to re-entering job details and chasing status. That's 24 hours a week, or 1,200 hours over 50 working weeks. If an hour of their time costs the company $35, that's $42,000 a year. The system won't remove all of it, so say it cuts the work by three quarters. Counted honestly: $31,500.
Errors. Over the last six months you can name roughly four mistakes a month that cost around $200 each in credits, rework and goodwill. The system would stop about three quarters of them. That's $800 a month, 75% prevented, so $7,200 a year.
Subscriptions. Three tools would go, adding up to $600 a month, or $7,200 a year. The new system's hosting and upkeep take back $2,400 of that. Net: $4,800 a year.
Cash. Invoices currently go out about a week late and get paid about two weeks after that. With invoices sent automatically and a pay button, say the gap shrinks by ten days. On $30,000 of monthly billing, that's roughly $10,000 of working cash released, once. Set it aside and don't count it in the yearly total.
The yearly gains: 31,500 plus 7,200 plus 4,800 is $43,500.
Now the cost side. Say the build costs roughly what those gains add up to in eighteen months. The payback lands at about a year and a half, and after that the system keeps returning $43,500 a year, plus whatever you decide to do with the freed-up cash.
That's the shape of a decent result: not a miracle, but a payback you can explain to your accountant. Change the inputs and the answer moves. Cut the hours in half and the payback stretches past two years. Double them and it shrinks to about ten months. That's why the exercise matters: you learn which inputs your decision hangs on.
The question isn't whether software can save money. It's whether it saves enough of your money, in the places where you actually lose it.
When the answer is "don't build it"
Sometimes the honest result of this exercise is a no, and we'd rather you hear that from us than learn it a year later.
If your hours bucket is small, say a couple of hours a week across the team, the payback will be long and you'll probably do better with a tidier use of the tools you have. If your process is still changing every month, you'd be paying to automate something that's about to move. And if nobody on your side will own the system afterward, the gains tend to leak away.
A subscription can also win outright when the task is a commodity. Payroll and basic bookkeeping are good examples. We walk through that tradeoff in detail in build vs buy software, including a seven-question test you can run in ten minutes.
There's also a middle road. If the numbers are promising but not overwhelming, build one piece, the part that causes the most pain, and see what it returns before committing to the rest. A phased plan like this keeps the risk small and the lessons cheap.
What drives the cost side
You can't finish a payback calculation without a cost, and we won't invent a figure here because it depends on your project. What we can do is tell you what moves it.
- How many kinds of users. Staff only is simpler than staff plus clients plus outside partners.
- How many workflows. One process done well costs less than ten done adequately.
- How many other systems it must talk to. Each connection adds work, particularly if the other tool is awkward.
- How polished the experience needs to be. A tool for four staff can be plainer than one your clients log into.
- What you want to carry over. Moving years of messy data takes real effort.
Our Price Guide lays out these drivers and the payment options, including 3, 6 and 12 month plans, so you can see how a project is shaped before you ever talk to anyone. If a proposal you've received doesn't explain what's driving its number, ask.
For a sense of how planning pays off, the U.S. Small Business Administration has a solid set of guides on budgeting and managing a business that are worth skimming before you set a number.
Check your own math this week
Don't try to do all of this in one sitting. Spread it out:
- Monday: list your software subscriptions and add up a year of each.
- Tuesday to Thursday: have your team keep a tally of re-entry, searching and chasing.
- Friday: write down the mistakes you can name from the last six months, with a rough cost.
- The weekend, if you must: put it into one sheet and apply the same haircut we did above, counting only what you're confident about.
If the total comes out small, you've saved yourself a project. If it comes out large, you now have a number to hold any proposal up against, and a shortlist of the gains that matter.
Either way you're no longer guessing, and you can have a much better conversation. Bring the sheet to a discovery call if you'd like a second pair of eyes. We'd rather help you find out the project isn't worth it than sell you one that isn't.