The default assumption in most businesses is that software should be bought, not built. This is a reasonable starting point — SaaS products are immediately available, maintained by someone else, and often priced in a way that makes the unit cost feel low. The assumption starts to break down when the business has grown to a point where no available product fits the process it actually runs.
The configuration trap
Every SaaS product is built for a generalised version of its intended user. The workflows it supports are the workflows that most of its customers have, shaped by the assumptions of the team that built it. When a business's actual process differs from that generalised model, it has two options: adapt the process to fit the tool, or configure the tool until it approximately fits the process.
Most businesses choose the second option and underestimate the cost. Configuration takes time — often significant time from people who could be doing higher-value work. The resulting setup is frequently fragile: it works as long as nothing changes, but requires rework every time the business evolves. And the tool still doesn't fit exactly, which means workarounds accumulate alongside the configuration.
When the economics shift
The economics of build vs buy shift at a fairly predictable point. When the total cost of workarounds, configuration time, and the productivity lost to an imperfect fit exceeds the cost of building something that fits correctly, building becomes the rational choice. For most businesses, this point arrives earlier than expected — often with a process that has five or more steps, involves data from multiple systems, or requires logic that no off-the-shelf product handles well.
Internal tools also have a compounding return that SaaS products don't. A custom tool built for your specific process can be improved over time in exactly the ways your business needs. It doesn't get features you don't need. It doesn't change its pricing model or deprecate functionality your team depends on. It's yours.
What good internal tools look like
The best internal tools are narrow and precise. They do one thing well, they connect to the systems the business already uses, and they remove a specific friction that was slowing people down. A custom onboarding workflow that connects HR to IT provisioning. A quoting tool that applies the business's actual pricing logic rather than a generic formula. A reporting dashboard that shows the metrics the leadership team actually uses, updated in real time.
These tools don't need to be complex to be valuable. The value comes from precision, not sophistication. A simple tool that exactly fits the process is worth more than a complex tool that approximately fits it.
The integration question
One of the most common reasons to build an internal tool is the integration gap between existing systems. Two platforms that both serve important functions but don't share data require someone to move information between them manually. This is expensive, error-prone, and slow. A custom integration — or a lightweight tool that bridges the gap — removes the manual step and makes both systems more valuable.
How to identify the right candidates
The clearest signal that an internal tool is worth building is when staff regularly work around the tools they have. If someone is exporting data from one system and re-entering it in another, if there's a spreadsheet that everyone treats as the source of truth alongside an official system, or if a process requires a sequence of steps that no single tool supports — these are signs that the existing tooling isn't right for the process.
The starting point is a conversation about the process, not the technology. What does the process need to do? Where does it break down? What would it look like if it worked exactly as it should? From those answers, it becomes clear whether the gap is fillable with configuration, an integration, or a purpose-built tool.