Bespoke AI software vs off-the-shelf: build or buy?

Every operational problem now has a dozen SaaS products claiming to solve it, and every business has processes those products don't quite fit. Here's the decision framework we use — including the cases where our answer is "don't hire us, buy the tool".

Question 1: Is your process a commodity or an edge?

Accounting, payroll, scheduling, generic CRM — commodity processes, superbly served off the shelf. Buy. But if a process is part of how you win — how you quote, how you source deals, how you deliver — then forcing it into someone else's software means working their way. Bespoke exists for the processes that make you different.

Question 2: How many tools does the work cross?

Off-the-shelf products are strong inside their own walls and weak across them. If your painful process spans four systems — enquiry in the inbox, job in the CRM, costs in the accounts, delivery in a spreadsheet — no single product fixes it, and you end up either re-keying (the thing you were trying to kill) or buying integration middleware that becomes its own project. Cross-system work is where bespoke usually wins.

Question 3: What does the cost curve look like at scale?

SaaS pricing is per-seat, per-month, forever, and rises as you grow. Bespoke is expensive up front, then costs maintenance. The crossover is often two to four years. Below it, buy; beyond it — if the process is stable and central — building starts to look like the cheap option. Factor in ownership too: bespoke means you own the asset rather than rent access to it.

The mistakes on each side

• Building a commodity. A bespoke CRM for a standard sales process is money on fire.
• Buying fifteen tools to avoid one build. The subscriptions quietly total more than the build would have, and the re-keying between them never dies.
• Building without a number. Bespoke only pays when it's pointed at a priced problem.
• Buying and abandoning. Software nobody adopted is the most common failed automation of all.

The honest sequence: audit first, so you know what the problem costs; check the off-the-shelf options seriously; build only where specificity, integration or scale justify it. That's the order we follow even though we sell builds — because a build pointed at the wrong problem fails, publicly, and we'd rather not.

← All notes