Run the three-year math first
Owners usually ask me whether custom software is worth it, and my first answer is always the same: run the numbers over three years, not one. Subscriptions look cheap monthly and expensive over time. Custom looks expensive up front and cheaper over time. Three years is long enough for the picture to flip, and short enough that your business will still look roughly like it does today.
Here is the basic comparison. A typical SaaS tool, meaning software you rent monthly rather than own, might cost 50 dollars per user per month. For a team of eight, that is 4,800 dollars a year, or about 14,400 dollars over three years. A small custom tool might cost 15,000 to 40,000 dollars to build, plus roughly 10 to 20 percent of the build cost per year to keep it healthy. On raw price, the subscription usually wins.
So the honest starting point is this: if a subscription fully solves your problem, buy the subscription. Custom software earns its keep somewhere else, and the next sections cover where.
When off-the-shelf is the right answer
My rule of thumb is the 80 percent test. If an existing product handles 80 percent of what you need, and the remaining 20 percent is stuff you can live without or work around in under an hour a week, buy it.
Some categories should almost never be custom-built for a small business:
- Accounting and payroll. The compliance burden alone makes this a terrible build.
- Email, calendars, and file storage. Microsoft 365 or Google Workspace do this better than anything I could build you.
- Basic CRM, meaning the system that tracks your customers and leads. Start with an off-the-shelf one.
- Scheduling and booking. Mature products exist at 15 to 50 dollars a month.
The pattern: if thousands of businesses have the exact same need you do, someone has already built it well, and their price is spread across all those customers. You cannot beat that economics with a custom build, and you should not try.
When a custom tool pays off
Custom software makes sense in two situations.
First, when the workflow is your competitive edge. If the way you quote jobs, route deliveries, or schedule crews is genuinely different from your competitors, generic software will flatten that difference. I build and run the online store for a DC flower shop that serves more than 15,000 customers, and the valuable part was never the shopping cart, because carts are a solved problem. It was the delivery logic specific to how that shop actually operates, which no off-the-shelf product handled.
Second, when the real cost is hiding in labor. If someone on your team spends five hours a week retyping data between two systems that will not talk to each other, that is roughly 250 hours a year. At a loaded cost of 35 dollars an hour, you are burning about 8,750 dollars a year on copy-paste. Over three years, that is more than 26,000 dollars, which is often more than the custom integration that would eliminate it.
Notice that the second case usually is not a full application. It is a connector, a small internal tool, or an automation. Those are the highest-return builds I do, and they are typically in the 5,000 to 20,000 dollar range, not six figures.
The three-year cost of custom, honestly
If you do build, budget for all of it, not just the build:
- The build itself. A small internal tool typically runs 10,000 to 50,000 dollars depending on complexity.
- Hosting. Usually 20 to 100 dollars a month for a small-business tool.
- Maintenance. Plan on 10 to 20 percent of the original build cost per year for updates, security patches, and small fixes. Software that nobody maintains rots.
- An internal owner. One person at your company needs to be responsible for the tool. Not to code, but to notice problems, request changes, and hold the vendor accountable.
If a developer quotes you a build price and goes silent about the other three lines, that is a red flag, not a bargain.
How projects become abandonware
Half-built custom software is worse than no custom software, because you pay for it and still do the work by hand. The failure pattern is almost always the same: big scope, long timeline, nothing usable until the very end, then the budget or the relationship runs out at 70 percent done.
The defense is boring and effective. Insist on a small first version that does one job end to end, delivered in weeks, not months. Insist on seeing working software every two to four weeks. Make sure the code lives in an account you control, is written in a mainstream stack, and comes with enough documentation that another developer could take over. Ask the developer directly: if you disappeared tomorrow, what happens? A good one has a specific answer.
What to do next
Here is the exercise I walk owners through, and you can do most of it in an afternoon:
- Write down the one workflow that annoys you most, and estimate the hours per week your team spends on it.
- Multiply hours per week by 50 weeks and by your loaded hourly cost. That is your annual pain number.
- Search for an off-the-shelf product that covers it. Price it for your team size over three years.
- If off-the-shelf covers 80 percent or more, buy it and move on.
- If nothing comes close, get a fixed quote for the smallest custom tool that solves just that workflow, plus honest maintenance and hosting numbers.
- Only proceed if the three-year pain number clearly beats the three-year build cost.
If you want a second opinion on the math, this is exactly the conversation I have with owners at HashWhales before any build, and about half the time my advice is to buy, not build.