Gustav Every growing business hits the same moment: a process that was manageable in a spreadsheet is now broken, a SaaS tool you bought two years ago does 60% of what you need, or a workflow that works fine for five people is crumbling at fifteen. Something has to change.
The question is always the same: do you find a better off-the-shelf product, or do you build something specific to your needs?
The answer is not as straightforward as either camp makes it sound.
The real cost of buying
SaaS looks cheap on the surface. A monthly subscription, no upfront cost, live in a day. But the full cost of a bought tool is almost always higher than the invoice.
Fit cost. No SaaS product is built for your specific business. You either adapt your process to fit the software, or you use the software in ways it was not designed for. Both have costs. Adapting your process means training people to work differently and losing the institutional logic baked into the old way. Using software wrong creates fragility, workarounds, and eventually a pile of data that does not transfer cleanly to whatever comes next.
Integration cost. Most businesses run five to fifteen SaaS tools. Getting them to talk to each other requires either expensive native integrations, paid middleware like Zapier, or a developer. The per-seat cost is just the start.
Switching cost. When the SaaS product raises prices, gets acquired, shuts down, or simply stops being the right fit, you have to move. The data migration, the retraining, the new integrations - these happen every few years, and they are never free.
The real cost of building
Custom tools have their own costs, and pretending otherwise leads to bad decisions.
Upfront cost. Building something good takes time and money. There is no way around this. A well-scoped, well-built internal tool costs more on day one than buying a SaaS subscription.
Maintenance cost. Software requires ongoing attention. Dependencies change, browsers update, integrations break. A custom tool that nobody is responsible for maintaining is a liability, not an asset.
Scope creep cost. The biggest risk with custom builds is building too much. Every feature request sounds reasonable in isolation. The sum of all reasonable requests is often a bloated, expensive system that is harder to maintain than the SaaS tool you replaced.
The three questions that actually decide it
1. Is this a commodity process or a competitive one?
If the process is something every business does - payroll, expense management, basic CRM - buy. There are excellent SaaS tools for commodity processes and building your own version is rarely worth it. If the process is something specific to how your business creates value - a workflow that is genuinely unique to your model, a tool that directly affects your output quality or speed - that is a candidate for custom.
2. How variable is it?
SaaS tools handle the standard case well and the edge case badly. If your process has a lot of variation - different clients, different rules, different outputs - a SaaS tool will accumulate workarounds until it becomes more painful than useful. Custom tools can be designed around your specific variation from the start.
3. What does it cost to be wrong?
Buying the wrong SaaS tool is usually recoverable - you migrate and move on. Building the wrong custom tool is more expensive to undo. If you are not confident about exactly what you need, buy something adequate, run it long enough to understand your real requirements, and then consider building if the gaps are large enough to justify it. The SaaS tool is a cheap way to learn what you actually need before you invest in something built to spec.
The best argument for building is not that SaaS is too expensive. It is that no SaaS product captures the specific logic of how your business works - and that logic is where your competitive advantage lives.
The middle option most businesses miss
The choice is rarely as binary as "buy a full SaaS product" or "build a full custom system." There is a middle path that is often the right answer: buy the commodity layer, build the custom logic on top of it.
Use an established CRM for contact management - Hubspot, Pipedrive, whatever fits - but build a custom layer that handles the specific qualification logic, the automated actions, the reporting that maps to how your sales process actually works. The CRM does the heavy lifting on data storage and UI. The custom layer does the intelligent, specific work.
This is where most of the interesting work in business tooling happens right now. The commodity infrastructure exists and is mature. The value is in the bespoke logic layer built on top of it - often small, fast to build, and precisely fitted to the way the business actually operates.
How to decide right now
If you are looking at this decision for a specific process in your business: start by mapping the process precisely. What does it do, what are the edge cases, what does "working well" look like? Then look at whether existing SaaS tools cover that map - not 60% of it, the actual map including the edges.
If there is a good fit, buy and move on. If there is not - if the gaps are in the parts of the process that matter most - that is when building, or building a custom layer, is worth the investment.
If you want a second opinion on a specific decision you are facing, get in touch. I have worked on enough of these to have a view on where the line usually falls.