When We Recommend Against Building Custom Software: A Documented Pattern

Editorial note: This article describes a pattern of decision encountered repeatedly across advisory engagements. It is not a single project narrative. The scenario is constructed from elements observed across multiple real situations. Where specific characteristics appear, they represent the class of situation being documented. Specific cost figures are excluded because they would require fabrication; the analysis describes cost structure relationships, not invented numbers.

There is a category of client request that we encounter regularly. A business owner or operations lead comes to us with a specific software problem they want to solve. They have looked at SaaS tools and concluded that none of them do what they need. They want to build something custom.

Our job, as they see it, is to confirm the requirement and start scoping. Usually, that is exactly what we do. But occasionally — more often than a software agency is supposed to admit — the right answer is to not build at all.

The Setup

The situations that produce this recommendation share a consistent shape. The client is running an operation — logistics, professional services, trades, agencies of various kinds. They have a process that works, but it is manual and fragmented: spreadsheets, email, WhatsApp, maybe one SaaS tool that doesn't quite connect to anything else.

They have been burned by SaaS before. A tool that promised to solve their workflow turned out to be built for a different kind of business. They lost data during a migration, or paid for features they never used, or found that the product roadmap stopped including what they needed. The conclusion they arrived at: they need to own their software.

What We Find in Discovery

In the cases that lead to the recommendation against building, there is typically a SaaS tool the client looked at briefly, found something they didn't like, and moved past. When we look at it more carefully, we find it does most of what they need — often the large majority of core requirements. The remaining requirements divide into two categories: things that genuinely require custom functionality, and things that are unusual about their current process rather than requirements of their underlying business.

The second category is the important one. Every business has workflows that have evolved around the constraints of their current tools. Some represent genuine competitive differentiation. Others are adaptations to limitations that wouldn't exist in a better-implemented SaaS tool. The difference matters enormously for the build vs. buy analysis. When we work through this distinction with the client, the custom requirements shrink — often enough to change the economic case.

The Analysis We Run

The standard build vs. buy comparison is project cost versus annual SaaS subscription. This comparison misses the costs that determine the actual long-term economics.

For the SaaS option, we add: onboarding cost (staff time to migrate, configure, and train), integration cost (any connections to other systems), and annual administration cost (who manages the tool, handles support cases, trains new employees). These are real, often significant costs invisible in the per-seat pricing.

For the custom option, we add: maintenance cost (who keeps this software running, updated, and secure after delivery), support cost (who handles bugs and user questions when the original team has moved on), and future development cost (any software that fits the operation today will not fit it perfectly in 18 months). For a business with no in-house developer, each of these is a dependency on an external provider.

When we add these categories to both sides, the economics shift. The SaaS option, which looked expensive because the annual subscription is visible, includes many of the ongoing operational costs in that subscription. The custom option, which looked like a one-time investment, carries ongoing operational costs that were invisible in the project quote.

What We Tell the Client

The recommendation against building is not primarily a cost argument. It is an organizational argument.

Every piece of custom software creates a dependency. For a business with in-house technical capability, this is manageable. For a business without it, the dependency is external — it lives in a relationship with an agency or freelancer that has to be maintained, funded, and managed. When that relationship breaks, the software becomes a liability. It runs, it probably keeps running for a while, and then one day it doesn't, and there is no one who knows how to fix it.

This is what we explain when we recommend against building. Not that custom software is bad, but that custom software without in-house capability is a long-term commitment that the project quote doesn't reflect. The quote covers the build. It doesn't cover the multi-year dependency that follows.

What Happens Next

Some clients agree and move to the SaaS tool. Some don't — usually because of a reason we don't know from discovery: a previous experience with vendor lock-in, a data sovereignty requirement, a future plan that makes the ownership case real. We don't fight clients who choose differently. We document the reasoning, note what our recommendation was, and build the best possible version of what they asked for.

In the cases where we recommended against building and the client proceeded anyway — and in those cases where we have been able to follow up on outcomes — the pattern of what followed has been consistent enough to be instructive. The software gets built. It works. The relationship with the agency winds down. The software runs without maintenance for longer than expected. Then it doesn't.

In the cases where we recommended SaaS and the client accepted, the follow-up pattern is different. There are complaints about the tool — there always are, because no SaaS tool fits every workflow perfectly. But the complaints are about specific features, not about existential software failure. The business is still running the software two years later.

What This Tells Us About How the Decision Is Made

The build vs. buy decision is not primarily a technical decision. It is not even primarily a financial decision, though the financials are part of it. It is a decision about what kind of operational dependency is acceptable.

Custom software is a dependency on your own capability to maintain it. SaaS is a dependency on the vendor's roadmap and pricing decisions. Neither dependency disappears by making the other choice. The question is which dependency you can manage better, given your actual team and your actual resources.

Most build vs. buy analyses compare the visible costs and ignore the operational dependencies. The recommendation against building emerges when we can see that the dependency implied by custom ownership is one the organization isn't resourced to manage — and when the SaaS alternative is close enough to what they need that the dependency on the vendor is more manageable than the dependency on custom code.