← Blog

Build vs buy: when should a small business build its own tool?

Buy versus build: the few SaaS features you actually use, plus the gaps you patch by hand, each copied one-for-one into a single custom tool Left, an off-the-shelf SaaS grid with only a few features used (blue), plus three manual gaps - spreadsheet, scripts, by hand. Seven arrows run one-to-one, each blue thing to its own box, into a single custom tool on the right that holds an exact copy of all seven. BUY: OFF-THE-SHELF SAAS Many features. You use a few. Spreadsheet Scripts By hand + the gaps you patch by hand. BUILD: ONE CUSTOM TOOL Your tool Exactly what you use - gathered in one place.
The scattered few SaaS features you use and the gaps you patch by hand - copied into one tool that is exactly your workflow.

Buy when the need is a commodity that thousands of businesses share. Build when the workflow is specific to how your business works and off-the-shelf software forces you into workarounds. That single distinction settles most build-vs-buy decisions - the rest is detail.

This isn't a cost comparison. It's a decision framework for picking the right side.

Default to buy

For most things, buying is correct. Email, accounting, payments, calendars, payroll - these are solved problems. Thousands of companies need exactly the same thing, vendors compete to do it well, and building your own would burn time and money for no advantage.

The test for "buy" is simple: is this need the same for you as it is for everyone else in your industry? If yes, a good off-the-shelf product is the cheap, sensible choice. Don't build what you can buy for the price of a subscription.

Build where the work is specific to you

The case for building gets strong in one situation: the workflow is particular to your business, and no generic tool models it well.

You can usually feel this without analysis. The signs:

  • Your team keeps a spreadsheet next to the SaaS tool to track what the tool can't.
  • Work gets copied by hand between two or three systems that don't talk to each other.
  • Onboarding includes a list of "just remember to do X" steps the software doesn't enforce.
  • You pay for a tool but use a fraction of it, and the part you need is missing.

Each of those is a workaround. Workarounds are invisible costs - they don't show up on an invoice, but they eat hours every week and create errors no one catches. When the workarounds cluster around the thing your business is actually good at, that's the workflow worth building for.

The decision in three questions

  1. Is the need a commodity, or specific to us? Commodity leans buy. Specific leans build.
  2. Does off-the-shelf software fit, or do we work around it daily? A clean fit leans buy. Daily workarounds lean build.
  3. Is this close to what makes us money, or is it back-office plumbing? Plumbing leans buy. Core workflow leans build.

If your answers point at specific, workaround-heavy, and core, you have a build candidate. If they point at commodity, clean fit, back-office, buy it and move on.

The build-vs-buy decision across three questions Three questions - the need, the fit, the work - each with a buy-leaning answer on the left and a build-leaning answer on the right. When the answers cluster on the right you build; when they cluster on the left you buy. BUY · rent it BUILD · own it THE NEEDTHE FITTHE WORK A commodityFits off-the-shelfBack-office plumbing Specific to youYou work around it dailyCore to what you do Answers cluster on the right? Build it. On the left? Buy it.
Three questions, two honest outcomes - build when the answers cluster on the right.

What changed about building

Building used to be the expensive option, which is why "buy" was almost always the safe answer. That assumption is dated. AI now does most of the build, so a custom tool typically costs a fraction of the old agency price, and arrives in weeks rather than months. You own it outright - the code, the documentation, the keys - on a standard stack any developer can maintain, with no monthly SaaS fees and no lock-in.

That shift moves the line. Workflows that weren't worth a custom build five years ago are now well within reach for a small business. The question is no longer "can we afford to build it" but "is this the kind of thing worth building".

A note on the middle ground

Most businesses don't choose one side for everything. You buy the commodity tools and build the one or two workflows that are genuinely yours. A custom tool can also sit on top of the SaaS you keep - pulling data out, removing the manual steps between systems, and giving your team the view the generic product never offered.

The goal isn't to replace everything you bought. It's to stop paying - in time and errors - for the gap between what you bought and what you actually do.

A simple test

Ask: would building this give us an advantage, or just rebuild something we could rent? If a tool would do what every competitor's tool already does, rent it. If it would do the thing only your team needs, in the order only your team works, that's where building earns its keep.

Start a project if you want a straight read on which of your tools are worth building and which to keep buying.

Email copied - valters@valters.solutions