I spent most of my career building software meant for thousands of customers. Now I build software for one business at a time. Having been on both sides, I don’t think the answer is always “build” or always “buy.” The answer depends on which process you’re trying to support.
Why off-the-shelf software feels like a compromise
When you build a product for thousands of customers, every change has to work for all of them. A feature that fixes one customer’s problem can make the product more confusing for everyone else, so product teams make careful tradeoffs. They decide what becomes a setting, what goes into the core product, and what they won’t support at all.
From the inside, those are reasonable decisions. From the customer’s side, they feel different. Your team keeps a spreadsheet next to the system because it misses a step you need. People enter the same information twice. You request a feature and wait to find out whether it fits the vendor’s roadmap.
Software sprawl makes this worse. BetterCloud’s 2025 State of SaaS report found the average company runs about 106 SaaS applications (BetterCloud). Every one of those tools brings its own idea of how your work should flow.
When buying is the right call
I tell people to buy software when the process is common and the product handles it well. Payroll, email, general accounting, and basic scheduling are good examples. Thousands of companies run those processes the same way, and a mature product has already worked through the edge cases.
Buying also makes sense when nobody on your side wants to own the software. Custom software is an asset, and assets need care. A common rule of thumb puts annual maintenance at about 15 to 20 percent of the original build cost (CodeStringers). If you aren’t ready for that, don’t build. Our guide to what drives custom software cost covers maintenance in more detail.
When building is the right call
Building starts to make sense when the process is part of what makes your business different, or when your team works around its software every day. These are the signs I look for.
- Data gets retyped from one system into another.
- A spreadsheet holds information the main system can’t handle.
- Important exceptions get handled in email or someone’s head.
- A system produces output, like PDFs, that you can’t export or connect to anything else.
- You pay for several tools that each solve a piece of one workflow.
Eagle Medical Billing is a good example. Their billing system produced PDF reports with no export and no API, so staff were retyping claim details into a spreadsheet. We built a platform that reads those PDFs, checks the details against existing records, and gives staff a queue for failed claims. At their claim volume, it avoided two full-time hires (Eagle Medical Billing case study).
What changed in 2026
Custom software used to be out of reach for most small businesses. It took a big team and a long timeline, and you paid for both.
AI has changed how quickly an experienced engineer can build. A good engineer can now get from a clear understanding of a process to working software in weeks instead of quarters. That doesn’t remove the need for engineering judgment. It changes the economics enough that more businesses should at least ask the question.
My prediction is that over the next two to five years, more businesses will build the systems that make them distinct and buy the rest. That’s already happening with the businesses we work with.
A simple way to decide
Ask three questions about the process you’re thinking about.
- Do thousands of other companies run this process the same way we do? If so, buy.
- Is our team working around our current software every day? If so, look at building.
- Will a custom system save more than it costs to build and maintain? If not, don’t build it.
At Hello Spark, we’ll tell you when a build isn’t worth it. Our method says so directly. If you have a process that doesn’t fit your software, tell us about it.