Build vs Buy: When Custom Software Actually Makes Sense

A framework for choosing between off-the-shelf tools, SaaS subscriptions, and custom development — what custom software really costs to own, and the middle ground most businesses skip.

Build vs Buy: When Custom Software Actually Makes Sense

Someone books a call and says they need "a system". Half the time, the honest answer is that a spreadsheet already does the job, or a subscription service does it for less than an hour of development costs. Custom software is the most expensive item on the menu and the right choice less often than people expect. But when it is the right choice, no off-the-shelf product will do. The skill is telling these cases apart before money is spent, and the decision comes down to three questions.

The three questions

  1. Does an existing tool do most of the job? If a ready product covers 80% of your process and the missing 20% is an inconvenience rather than a blocker, buy it. Paying a developer to rebuild invoicing or a helpdesk is paying to lose features the vendor will ship next quarter.
  2. Is your process standard or genuinely different? Invoicing, CRM, scheduling, email marketing: all standard. If your workflow is the same as everyone else's, that's a feature of your industry, not a problem to solve. Custom code earns its keep when the difference in your process is the point.
  3. Who maintains it afterwards? Every custom app has a maintenance tail. If nobody will own the code, you're buying a liability, whatever it says in the proposal.

What custom actually costs

The build price is the down payment. After launch come hosting, security patches, dependency updates, framework upgrades every few years, and a developer to call when something breaks at 9am on a Monday. None of that is waste; it's the cost of owning software, the same way a delivery van costs tyres and inspections after you buy it.

Off-the-shelf software hides the same costs inside a subscription. You don't patch it, but you also don't control its roadmap, its export formats, or its price increases. When you compare, compare three-year totals: subscription cost versus build cost plus realistic maintenance. Sometimes the subscription wins even at scale.

When building wins

  • The workflow itself is your advantage. If competitors could buy the same tool tomorrow, it isn't a moat. If your edge is a process nobody else has, software that encodes it is an asset.
  • You need to integrate with something strange: a legacy ERP, a national registry, a supplier's ancient file format. SaaS products connect to mainstream systems. Glue to the unusual has to be written.
  • Per-seat pricing has outrun you. Twenty seats of a €15/user tool is a rounding error; four hundred seats of it is a build case.
  • The data model is yours. Businesses whose core object doesn't fit any vendor's schema end up fighting the tool forever.

When buying wins

  • The process is standard and will stay standard.
  • You need it working this quarter, not in three months.
  • Requirements are still fuzzy. Buying a mediocre tool for six months teaches you more about what you actually need than a discovery phase does, and it's cheaper. Building before you know your own process is how people end up rebuilding their custom app a year later.
  • No one in the company can own code. A subscription degrades gracefully; an orphaned codebase doesn't.

The middle ground most people skip

Between "buy a SaaS" and "build a system" sits a large grey zone: small custom tools built around existing services. A script that pulls orders from the marketplace API and pushes them into your accounting tool. An internal admin page in front of a shared spreadsheet. A webhook that connects two SaaS products that don't talk to each other. This is often days of work, not months, and it solves the actual problem, which is usually one broken step in the middle of an otherwise fine process.

When a client comes to us with "we need a system", the first thing we ask for is a written description of the current process, end to end. If it doesn't fit on one page, that's the finding: nobody knows the process, and no software will fix that. If it does fit on one page, the right intervention is usually visible immediately: a subscription here, a small custom piece there, and real custom development only where the business is genuinely different.