I turn down custom-software projects fairly often. Not because I don't want the work — I build software for a living — but because the honest answer to "should we build this?" is sometimes "no, buy the off-the-shelf tool and save your money."
That surprises people. They expect a developer to say "yes, let's build it." But the fastest way to lose a client's trust is to build them something they didn't need. So before I quote anything, I help businesses figure out whether custom software is even the right call. Here's how that decision actually works.
The three options, honestly
When a business has a software problem, there are really three paths — and most people only seriously consider one.
Buy off-the-shelf (SaaS). Someone has already built a product for your need. Fast, cheap to start, well-supported. This is the right answer far more often than custom-software vendors admit. If your need is generic — CRM, accounting, email, project management — a product almost certainly does it better than anything I'd build from scratch.
No-code / low-code. Tools like Airtable, Make, or a form builder. Brilliant for prototypes, simple internal tools, and proving an idea before you invest. The catch: they hit a ceiling, get fragile as they grow, and are hard to hand to a developer later. Great for "will this even work?", risky for "this now runs our business."
Custom software. Built specifically for you. The right answer when the process is your advantage, when no product fits, or when you're paying so much in SaaS fees and manual workarounds that building pays for itself. More expensive upfront, and it has to be built properly — or it becomes the very problem it was meant to solve.
The mistake isn't choosing wrong between these. The mistake is not knowing which one you're actually in.
The question that decides it
Strip away the technology and ask one thing: is this process generic, or is it how we win?
If the answer is "generic" — every business does invoicing, scheduling, email — then buy. Don't build a custom CRM because your sales team finds Salesforce annoying. The annoyance is cheaper than the build.
If the answer is "it's how we win" — a workflow specific to your business, a way of serving clients that competitors can't copy, a process that is your edge — then a product will never quite fit, and custom software starts to make sense. You don't want to bend your advantage to fit someone else's tool.
Most real cases sit in between, and that's where the interesting answer lives: a thin custom layer on top of bought tools. Keep the SaaS for the generic 80%, and build the specific 20% that actually matters. That's often the cheapest, smartest option — and almost nobody pitches it, because it doesn't sell a big build.
When "build" is genuinely right
In my experience, custom software earns its place when several of these are true:
- No product does the missing 10% — and that 10% is the whole point.
- You're drowning in workarounds — spreadsheets, copy-paste between tools, manual steps that should be automatic.
- The SaaS bill has crept up — per-seat costs over three to five years now rival the cost of building.
- You're locked into a vendor you'd struggle to leave, with your data inside their walls.
- The process is a real advantage you want to own outright, not rent.
If three or more of those ring true, it's worth pricing a build properly. If only one does, be suspicious of anyone — including me — who tells you to build.
The mistakes I see most
Building too early. Custom software before you've validated the process with a spreadsheet or a no-code prototype. Build once you know what you need, not to figure out what you need.
Building too broad. "While we're at it, could it also…" is how a focused €15k tool becomes a stalled €60k platform. The best builds do one thing well, then grow.
Buying when you should build the 20%. Forcing your business to work the way a product wants, when a small custom layer would have let you keep your edge.
No-coding the thing your business depends on. No-code is perfect until the day it isn't — and the rebuild costs more than building it properly would have in the first place.
Forgetting who owns it on day 366. Custom software needs an owner — someone who maintains it, extends it, fixes it. If the answer to "who owns this after launch?" is a shrug, slow down.
How I scope it before quoting
When someone comes to me wanting a build, I don't start with technology. I start with three questions:
- What's the specific problem, in one sentence? Not "we want a better system" — "we spend forty hours a month manually reconciling orders between our shop and our warehouse, and mistakes cost us returns."
- What does success look like in 12 months? A measurable operational difference, not "the software is live."
- Can it ship in phases? A good build delivers something useful early, then grows. Anyone quoting one big nine-month bang is taking on risk you'll pay for.
Only after those do we talk about what to build and how much. And sometimes that conversation ends with me saying "honestly, buy this SaaS product and call me if you outgrow it." That costs me a project and earns me a client for life.
One more thing: how you pay for it
A real barrier for smaller companies is cash flow — a custom build is a meaningful cheque to write upfront. So I offer a choice: pay it as a project, or as a fixed monthly fee over an agreed period. Same work, same ownership, gentler on the bank balance. If the only thing standing between you and the software you need is the shape of the invoice, that's a solvable problem.
I build production-grade custom software for Belgian businesses and agencies — as a project from €10k, or a fixed monthly fee. No junior hand-offs, you own the code, and AI gets woven in only where it genuinely helps. If you're weighing a build, start with a 30-minute call — I'll tell you honestly whether it's worth doing, or point you at the off-the-shelf tool that isn't.
There's also a free Build vs. Buy decision guide — a scorecard and an honest cost reality to work through before you commit. And I write a short, practical newsletter for Belgian businesses on software, AI, and senior engineering; subscribe below if that's useful.