Should we build custom software or buy SaaS?

The test: three questions, in this order

Most build-or-buy arguments skip straight to cost. Start with the gap instead.

1. Does a tool already do this? If your process looks like most businesses’ version of it, buy. Billing, payroll and standard accounting are not where a custom build earns its keep.
2. Can you configure what you already own? Many “we need new software” requests are really “we never trimmed the old one.” Hide unused fields, give each role its own screen, merge duplicates. That is admin work, not development.
3. Is the gap a workflow, or a handoff? If no tool covers the workflow, or the same fact gets typed into two tools by hand, a custom build is on the table. Even then, build the smallest thing that closes the gap.

Why owners ask this

The fear behind the question is paying twice: once for a custom build that a subscription would have covered, and again to maintain it. The opposite fear is just as real: a SaaS tool that fits 70 percent of the job, with the last 30 percent living in a spreadsheet nobody trusts. Neither fear is silly. The test above is meant to make the choice something you can explain to your partners.

What good looks like

A sound build-or-buy decision leaves a short paper trail you can check on any vendor, including us:

• A list of the five tasks each role does every day, written from watching them work, not from a feature wish list.
• A note on what the existing tool can already do with its own layout and permission features.
• A count of where the same fact is typed. Every extra place is a place data goes stale.
• A build that sits beside the core tool, not inside it, and talks to it through its API.
• A retirement date for anything custom. Custom pieces that nobody dares touch become the next clutter problem.
• A three-year total for each option, including exit cost.

In our own reading of the complaints buyers post about their CRM and ERP tools, many of the fixes turned out to be configuration or cleanup. A smaller share needed new software, and it was nearly always a thin layer: a sync from where data is born, a dashboard per role, a phone capture screen. That is our reading of public reviews, not a measured result.

How we’ve seen it: one build stayed a spreadsheet, one couldn’t

The sheet. For a coaching institute we built a 16-sheet Excel system that covers syllabus tracking, attendance, timetables and test records. The syllabus tracker alone covers 320 topics across five board-and-subject combinations. We built a spreadsheet there, not an app. The reason it can work is the shape of the job: a small team, one structure, one owner. The moment several counsellors need to edit the same record at once, or the work moves to phones, that is the part to move into a shared app. We haven’t measured hours saved, so we don’t claim any.

The queue. For a clinic client we built the opposite. A live queue that patients, reception and doctors all see and change at the same time can’t live in a sheet. Three roles need different views of the same data, updates must reach a phone in real time, and each role must only touch its own rows. That is why we built a platform: the case study has the detail, and it is also unmeasured.

The same company chose a sheet for one client and a platform for the other. What decided it was the shape of the job, not a preference.

Where this doesn’t apply

Questions to ask any vendor, including us

1. Which of my five daily tasks does an existing tool already cover?
2. What can I configure in what I own before you build anything?
3. Where will you build: inside my core tool, or beside it?
4. What gets a retirement date, and who owns that date?
5. What does it cost to leave in year three?

Next: what should go in version 1 of a custom platform, and how to vet a software vendor. Both belong to our guide, Buying custom software and hiring a tech vendor.