← The build log

Buy vs build: when custom software beats another SaaS subscription.

A plain decision framework for SMB teams — when an off-the-shelf tool is the right call, and when your process deserves its own system.

Buy when your process is standard. Build when your process is your edge. That’s the whole framework — the expensive mistake is forcing a standard tool onto a process it was never designed for, and then paying people to work around it every day.

Most companies need both, so the real question is where to draw the line. Here’s how to find it.

The real cost of “just buy a tool.”

A subscription looks cheap next to a build quote. The costs that don’t show up on the pricing page:

  • The 80% fit. The tool does most of what you need — and the missing 20% becomes manual work forever. That gap is where evenings go.
  • Per-seat creep. Twelve euros a month becomes serious money once every teammate, freelancer, and viewer needs a seat, for every tool, for years.
  • The workaround layer. Spreadsheets that patch what the tool can’t do, exports that get re-imported somewhere else, one person who “knows how the system works.”
  • Your data, spread thin. Five tools means five half-pictures of your company and no complete one.

None of this makes buying wrong. It makes the default to buy wrong.

When buying is the right call.

Be honest here — building has costs too, and standard problems deserve standard tools:

  • The process is the same at every company: accounting, e-mail, calendars, payroll, video calls. You will never out-build Exact or Gmail, and you shouldn’t try.
  • The tool fits 95%+ out of the box and the last 5% genuinely doesn’t matter.
  • You’re testing a new process and don’t yet know what you need. Rent first, learn, then decide.

When building wins.

  • The process is your edge. If how you quote, plan, deliver, or follow up is why customers pick you, a generic tool actively flattens your advantage into everyone else’s workflow.
  • The work lives between tools. No product fixes the copying between your webshop, your planning sheet, and your invoicing — a small custom system that connects them does. That’s most of what we build as custom software.
  • You’re paying for ten tools to approximate one system. At some point the subscription stack costs more than owning the real thing.
  • Ownership matters. Your data, your code, your accounts — no platform sunsetting a feature you depend on, no price change you can’t refuse. You own everything we build.

The economics changed — recently.

The old argument for buying was that building took six months and six figures. That argument is aging fast: modern AI-era processes ship working systems in weeks (we run a software factory built exactly for this). The break-even between “rent forever” and “own it” has moved, and it keeps moving in ownership’s favor.

A simple decision test.

Five questions. Count your yes-answers:

  1. Does this process touch money or customers directly?
  2. Is it done differently here than at your competitors — on purpose?
  3. Does someone spend hours per week moving data between tools for it?
  4. Have you already built spreadsheet workarounds on top of an existing tool?
  5. Will you still run this process in three years?

Zero to two: buy the tool. Three or more: the process is telling you it wants its own system.

If you’re on the fence, describe the process to us on a discovery call — we’ll tell you honestly which side of the line it falls on. Sometimes the answer is “keep the subscription”; that’s a useful call too. The stories on our success stories page show what the other answer looks like.

Fair questions.

01 Isn't custom software expensive to maintain?

It doesn't have to be. A well-built system on boring, proven technology needs modest upkeep, and you can pay for maintenance as a service instead of hiring for it. What you stop paying is the per-seat subscription that grows every time your team does.

02 What if we outgrow the custom system?

Outgrowing custom software usually means extending it — which you can, because you own the code. Outgrowing a SaaS tool means migrating everything out of it. Ownership ages better.

03 Can a custom system work with the tools we keep?

Yes — that's usually the point. Most systems we build sit between the tools a company keeps (accounting, e-mail, webshop) and replace only the manual glue: the copying, checking, and re-typing between them.