When to buy, when to build: the honest business case for custom software

A CEO asked us last month: "At what point should we stop stitching SaaS tools together and just get something built?"

The honest answer is that the moment is later than most people think, and earlier than the "it's fine, we'll just add another Zap" crowd will admit. Custom software is expensive. It is also, in the specific situations described below, the option that pays back the most over the next thirty-six months. Getting the timing right — building custom neither too early nor too late — is the whole discipline.

Here is the framework we walk businesses through before we quote.

The four options, plainly

Every business tool your team uses lives in one of four categories. Naming the category is the first thing we do.

1. Off-the-shelf SaaS. Salesforce, HubSpot, Notion, Slack, Google Workspace, Stripe. Someone else built the software and rents it to you. Fast to start, monthly per-seat pricing, minimal customisation.

2. Low-code / no-code platforms. Retool, Airtable, Webflow, Zapier, Make. You build within someone else's runtime, using their components. Faster than custom, more flexible than pure SaaS, still dependent on the platform's ceiling.

3. Spreadsheets and internal glue. Google Sheets, Excel, a shared Notion. The default for anything new. Cheap, familiar, infinitely flexible, and quietly the most common load-bearing software in most companies.

4. Custom software. Something we build for you, on your stack, that you own. Highest up-front cost, lowest ongoing per-seat cost, maximum flexibility, maximum accountability.

Most tools your team uses should stay in categories 1–3. Custom software is for a small set of situations where the other three have run out of runway. Naming which category a given problem belongs in — instead of jumping straight to "can you build us X?" — is the conversation that saves the most money.

The four signals it's time to build custom

If you can honestly say yes to three of these, it is time to commission real software. Fewer than two, it isn't yet.

1. The business process is your differentiator. Every business has processes it shares with competitors (payroll, accounting, support tickets) and processes that make it specifically good at what it does. If your differentiator is running on off-the-shelf software your competitors also use, the software cannot be a differentiator. Custom is how you build the moat.

2. You have outgrown your platform's ceiling. Every SaaS and low-code tool has a wall. It shows up as "we need this workflow but the platform doesn't support it," or "we've built six workarounds to make it do the thing," or "our best operators spend hours a week on manual data movement between two tools that should talk to each other." If you have hit the wall three times, the wall is not the exception. The tool has outgrown you.

3. Per-seat pricing has become an unlevered cost. SaaS pricing compounds silently. At fifty people it is a rounding error. At five hundred it is a real budget line. When you find your team avoiding hiring because "the software cost per head is too high," the cost model has broken and custom starts to earn back over 24 months.

4. You cannot get your data out cleanly. Someone else's software is fine when they have your data. It stops being fine when you need to run analysis they don't support, migrate to a successor, or comply with a regulation that requires local custody. Data lock-in is a hidden cost that shows up as either compliance risk or the inability to move.

Three of the four → build. Fewer than two → keep buying, and revisit in six months.

The two questions we ask before we quote

Once the signals point toward custom, we ask two questions. If either answer is soft, we push back on the whole idea.

Question 1: What changes for the business when this ships? If we cannot describe the outcome in a paragraph — revenue unlocked, cost taken out, a specific decision made faster — then we don't have a custom software project yet. We have a hypothesis. Hypotheses belong in a prototype, not a nine-month build.

Question 2: Who owns this once it's live? Custom software is not a one-time delivery. It is an ongoing responsibility. A dedicated internal owner, a plan for future changes, and a budget for the small amount of ongoing engineering that any real software requires. Without those three, we've watched excellent custom software get abandoned in ninety days.

If you can't answer both in a paragraph, we don't have a project yet. We have a hypothesis — and hypotheses run through the two-week prototype phase we describe in our process, not straight to a full build.

The comparison over 24 months

Sticker cost is a misleading way to compare, because it ignores what the tool actually costs to run the business on for two years. Here is the honest picture for the same hypothetical mid-sized business need — a workflow used by twenty operators daily.

	Off-the-shelf SaaS	Low-code	Custom software
Time to first version	Days	2–6 weeks	12–20 weeks
Up-front cost	Low	Medium	High
Cost per user, per month	High	Medium	Near-zero
Match to the business	Approximate	Close	Exact
Data ownership	Someone else's	Someone else's	Yours
Ceiling on customisation	Low	Medium	None
Total 24-month cost (20 users)	~$180k–$300k	~$120k–$180k	~$180k–$260k build + minimal run
What you own at the end	A subscription	A platform binding	Software + IP

The pattern people miss: for anything more than a handful of users, the 24-month cost of the "cheap" SaaS option is often close to or more than the "expensive" custom build — and at the end of the SaaS window you own nothing. That comparison isn't visible until you actually total it up. Most businesses never do.

Where NOT to build custom

We are honest about the shape's limits. Do not build custom when:

• The process is standard and there is a mature SaaS category serving it (accounting, CRM, payroll — you're not going to beat Xero, Salesforce, or Rippling by rebuilding them).
• The team using the tool is three people. That is a spreadsheet-shaped problem, not a software one.
• The decision-maker asking for it is doing it for status reasons. "Every serious company has custom software" is not a signal. It is a rationalisation.
• You do not have a named owner for the tool post-launch.

Custom software you don't need is worse than a spreadsheet you do.

The answer

Build custom when the process is a differentiator, the current tools have hit their ceiling, per-seat pricing has become unlevered, or the data must be yours. Buy off-the-shelf for the standard categories. Live on a spreadsheet until it breaks. Everything else is variation on the same theme.

If you're weighing this call for a specific problem, we're happy to walk through it. See how we scope custom software work, or send us a short brief. We reply within one business day.