A client came to me last year with a request I had heard many times before in different forms: “We have been using [name of popular SaaS tool] for three years. It worked when we were small. Now it is causing us real problems and we cannot figure out if we should fix our process to match the tool or replace the tool entirely.”
The answer to that question — whether to adapt your process or replace the tool — is one of the most important technology decisions a growing business makes. Getting it wrong in either direction has significant consequences. Adapting your process to fit a tool that fundamentally does not match your operation means your business runs slower than it should, permanently. Replacing tools too frequently creates switching costs and staff retraining overhead that adds up across an organisation.
I have been a custom software developer for twenty-two years. I have built systems for businesses of every size, in industries from healthcare to logistics to financial services. The pattern I see most often is not “off-the-shelf software is bad.” Most off-the-shelf software is competently built for the use case it was designed for. The pattern is “off-the-shelf software is being used for a use case it was not designed for, and nobody has noticed yet.”
Here is when that happens, why it happens, and what the right response actually is.
Why Off-the-Shelf Software Fails at Scale
Off-the-shelf software is built to solve common problems for the average user in a given category. That is its strength — it works immediately, requires no development, and has been tested by thousands of other businesses in similar situations. For businesses operating at average scale with average requirements, it is an excellent solution.
The failure mode appears when a business stops being average in the ways that matter.
Volume that exceeds the product’s design assumptions
Most SaaS products are designed around a typical customer size. When your usage is ten times the typical customer’s, you start hitting limits that were designed with typical customers in mind — database query timeouts that did not matter at low volume, export functions that cannot handle records in the hundreds of thousands, dashboards that load slowly when they were designed for much smaller data sets.
Some products handle this well — their architecture was designed to scale. Many do not, and the only indication is degraded performance that gets gradually worse as you grow, until something breaks completely or the system becomes too slow to use effectively.
Workflow requirements that do not fit the product’s model
Every software product embeds assumptions about how its users work. A project management tool assumes projects have tasks, tasks have assignees, and progress is linear. A CRM assumes sales happen in a pipeline with stages. An inventory system assumes products have fixed attributes and are sold through standard fulfillment.
When your business works differently — when your projects have complex dependencies, when your sales process has non-standard branching, when your products have variable attributes that the inventory system cannot represent — you spend time fighting the tool rather than using it. Workarounds multiply. Staff develop parallel processes in spreadsheets to compensate for what the official system cannot do. The SaaS subscription remains in place but the actual work happens around it, not through it.
Integration requirements that accumulate
No business runs on one system. A growing business runs on many: CRM, inventory, billing, HR, payroll, shipping, communication tools. Each system talks to some others through integrations — APIs, webhooks, data export/import flows. When the integration requirements become sufficiently complex, the integration layer itself becomes a project. A business running seven SaaS tools with fourteen integrations between them is managing a small middleware infrastructure. When any tool changes its API or pricing, all integrations that touch it need review. The overhead of managing the SaaS stack becomes comparable to the overhead of managing custom software.
When to Build Custom
I am going to be honest about the threshold because I see it understated regularly: custom software is the right answer in fewer situations than most people think, but in the situations where it is right, the ROI is significant.
Custom software makes sense when:
- Your core business process is your competitive advantage. If the way you do things is proprietary — if a competitor using the same generic SaaS would operate identically to you — then you have nothing worth building custom. If the way you do things is genuinely different and better, that process is worth encoding in software that enforces and accelerates it.
- Off-the-shelf tools require substantial workarounds to fit your process. If your team spends significant time per week compensating for things the software cannot do, quantify that time in cost terms. That number is what custom software is competing against.
- You have a stable core process that will not change significantly. Custom software is expensive to change. If your business process is still evolving rapidly, build on flexible off-the-shelf tools until the process stabilises. Then build custom around the stable core.
- The long-term cost of the current approach exceeds the custom build cost within three to five years. This is the calculation most businesses do not make but should. See the comparison table below.
The Build vs Buy 5-Year Cost Comparison
| Cost category | Off-the-shelf SaaS stack | Custom software |
|---|---|---|
| Year 1 cost | $12,000-$36,000 (licence fees) | $25,000-$80,000 (development) |
| Year 2-5 annual cost | $12,000-$48,000 (escalating as you grow) | $3,000-$8,000 (maintenance, hosting) |
| Integration management overhead | High (multiple APIs, changes propagate) | Low (single system, owned codebase) |
| Workaround staff time cost | High (ongoing) | Minimal (built for your process) |
| Switching cost when SaaS changes pricing | Full replacement cycle | None |
| Data ownership | Vendor dependent | Full ownership |
| Vendor risk | Acquisition, shutdown, pricing changes | Depends on developer relationship |
| 5-year total (typical mid-market business) | $80,000-$220,000 | $40,000-$110,000 |
The custom software option has a higher Year 1 cost. Over five years, it is typically less expensive than a growing SaaS stack for a mid-market business — particularly when you factor in the time cost of workarounds, integration management, and the periodic crisis that happens when a key SaaS tool changes significantly.
The comparison numbers vary significantly by industry and business size. The principle holds across most situations: upfront development cost is not the same as long-term cost.
When Not to Build Custom
Equally important: the situations where custom software is the wrong answer, even when it feels like the right one.
- When the off-the-shelf tool would work if you were willing to change your process. Before building custom, ask honestly whether the issue is the tool or the process. Sometimes the SaaS product is better at the job than your current process, and the resistance to it is about change rather than fit.
- When your business is changing too fast to build around. A startup whose core model is still evolving should not build custom until the model stabilises. Custom software encodes assumptions about how the business works. If those assumptions are wrong six months later, the software is wrong too.
- When the volume of transactions is low enough that manual process is acceptable. Not every inefficiency justifies software development. If a manual process takes two hours per week and the business is otherwise healthy, the custom software ROI calculation may not close.
The Developer Relationship Question
One risk with custom software that the build-vs-buy comparison tables do not capture is developer dependency. Custom software is maintained by people who understand it. If the relationship with the developer ends and the codebase is not well-documented, the cost of bringing a new developer up to speed or re-implementing can erode the initial savings.
This is a real risk and one I take seriously in my own practice. The software I build for clients is documented, built on standard technologies, and delivered with code that a competent developer can maintain or extend without me. Client lock-in through obscure code or proprietary frameworks is not something I consider acceptable — and it should not be something you accept from any developer you hire.
Before committing to any custom development engagement, ask the developer explicitly: if we need to hand this to another developer in two years, what does that look like? The answer tells you a great deal about the quality of what you are about to receive.
What Working With a Custom Software Developer Actually Looks Like
Clients who come to me for the first time often expect custom software development to be a lengthy, expensive, and unpredictable process. That expectation comes from stories of enterprise software projects that ran over time and budget. Those stories are real, and the cause is usually the same: unclear requirements, scope creep, and poor communication between the business and the developer.
The projects I run are structured to prevent those failure modes. Requirements are documented and agreed before development begins. Scope changes are tracked and priced separately so neither party is surprised. Working software is demonstrated in regular intervals — you see what you are getting before it is finished, not only at delivery.
The single most important thing a business can do to ensure a good custom software outcome is to have a clear picture of what the software needs to do before development starts. Not every technical detail — that is the developer’s job. But the business process, the key workflows, the edge cases that the general description does not cover. The better the requirements documentation, the more accurate the estimate, the fewer surprises during development, and the more closely the finished product matches what you actually needed.
Quick Summary
- Off-the-shelf software fails for growing businesses when volume exceeds design assumptions, when core processes do not match the product’s built-in model, or when integration complexity becomes a management overhead in itself.
- Custom software is right when your process is your competitive advantage, when workarounds are consuming significant staff time, when your process has stabilised, and when the 5-year cost of off-the-shelf exceeds the custom build cost.
- The 5-year cost comparison typically favours custom software for mid-market businesses — but Year 1 cost is higher, which is why the calculation is often not made.
- Developer dependency is the main risk in custom software — mitigated by using standard technologies, good documentation, and a developer who explicitly plans for the possibility of handover.
- Good requirements documentation is the single largest predictor of a successful custom development outcome.
The question is not whether custom software is “better” than off-the-shelf. For most businesses at most stages, off-the-shelf software is the right answer. The question is whether you are in one of the situations where it is not — and whether you have calculated the actual cost of staying with a tool that is not working well enough. If you are at that point, I build the custom systems that replace it.