A business asks whether to build a system or buy one. The conversation immediately becomes a feature comparison, then a cost comparison, and the decision gets made on a spreadsheet comparing a licence fee against a development quote.
That spreadsheet compares the two smallest numbers in the decision and ignores the one that determines the outcome. Software you buy is maintained by someone whose entire business depends on maintaining it. Software you build is maintained by you, for as long as you use it, and that obligation does not appear in the quote.
The useful question is narrower than build or buy. It is whether this particular workflow is one where your business genuinely differs from every other business that does the same thing — because that is the only condition under which owning the software is worth what owning it costs.
The question that actually decides it
Software supports a process. The relevant property of that process is whether it is one you share with every competitor or one that constitutes part of your advantage.
| Workflow type | Examples | Sensible default |
|---|---|---|
| Universal | Payroll, accounting, email, document storage, HR records | Buy. There is no version of these that is yours, and vendors have solved them at a scale you cannot match |
| Common with local variation | CRM, project tracking, support desk, inventory | Buy and configure. Where configuration is not enough, extend through the API rather than replacing |
| Genuinely distinctive | The specific way you price, schedule, allocate or fulfil, where that method is why customers choose you | Build, if it is not adequately served by anything available |
| Distinctive but not differentiating | Processes that are unusual because of history rather than design | Fix the process first. Building around an accident makes it permanent |
The fourth row is the one worth dwelling on. Businesses frequently describe a process as unique when it is merely idiosyncratic — the result of a decision made years ago by someone who has left, preserved because changing it would be disruptive. Building software around that encodes it permanently and makes the eventual correction more expensive, not less.
The distinction is testable. Ask why the process works the way it does. If the answer describes a deliberate advantage, it is distinctive. If the answer is that it has always been that way, it is history.
What each model actually costs
Both models hide costs, in opposite directions, which is why the headline comparison misleads so reliably.
| SaaS | Custom | |
|---|---|---|
| Visible cost | Per-user subscription, growing with headcount | One-off build, quoted before work starts |
| Hidden cost | Tier jumps to unlock one feature; paid connectors; the roadmap being someone else's | Hosting, patching, dependency upgrades, framework migrations, and an engineer available when it breaks |
| Cost trajectory | Rises with the thing you are trying to grow | Falls per user, rises with time and neglect |
| Who fixes it | The vendor, to their timetable | You, to yours — if someone is available |
| Cost of leaving | Export limits, API quotas, data formats | A codebase somebody must keep running or replace |
| Worst case | A feature you depend on is deprecated | The person who built it leaves and nobody can modify it |
The final row on the custom side is the failure that ends most custom software prematurely. It is not a technical failure and no amount of engineering quality prevents it — it is an ownership failure, and it is addressed by contract and documentation rather than by code.
On the SaaS side, the trajectory row is the one that changes the answer at scale. Per-user pricing means the software costs more precisely as the business succeeds, and there is a size at which that arithmetic stops working. That point is worth calculating in advance rather than discovering.
The middle path most businesses need
Presented as a binary, this decision forces a choice between two expensive commitments. In practice there is a progression, and most requirements are satisfied before the end of it.
- 1
Configure what you have properly
Most business software is configured once during onboarding, against the process as described rather than as performed, and never revisited. A week spent re-modelling objects, fields and permissions against current reality resolves a surprising proportion of what gets presented as a software limitation.
- 2
Fix the process before automating it
Where two teams disagree about what a stage means, no software resolves it. Automating a disputed process produces a faster disagreement.
- 3
Integrate what is stranded
A great many requests for custom software are really requests for two systems to agree with each other. Connecting them through their APIs is a fraction of the cost of replacing either.
- 4
Extend, rather than replace
Build the one workflow that genuinely does not fit as a separate application that reads and writes through the existing system's API. The platform stays the record of truth; you own only the part that is actually yours.
- 5
Replace only with evidence in hand
By this point the process is documented, the integrations are mapped, and you know exactly which requirements the platform cannot meet. That is the specification a custom build needs, and the thing most failed builds never had.
Reaching step five having done the first four is a materially different position from starting there. The work is not wasted if you do build — it is precisely the input the build requires.
When building is the right call
There are genuine cases, and it is worth being clear about them so the decision is not always deferred.
- The workflow is the product. Where the way you do something is why customers choose you, buying a generic version of it means competing on someone else's terms.
- Scale has broken the pricing model. Where per-user or per-record costs have grown beyond what a build plus its maintenance would cost across a realistic horizon.
- Regulation requires control of the estate. Where a supervisory requirement means the data and the processing must stay somewhere specific and under your control.
- The integration burden exceeds the application. Where so much custom work surrounds a bought system that the system is providing little of the value.
- Nothing adequate exists. Genuinely, after looking — this is rarer than assumed and is the justification most often claimed without a search.
Common mistakes
| Mistake | Why it happens | What to do instead |
|---|---|---|
| Comparing licence fee against build quote | Both are single numbers and appear comparable | Compare annual cost of ownership across three to five years |
| Building to capture the last ten per cent | A bought system does ninety per cent and the gap is visible | Extend through the API; owning the whole thing to fix a tenth of it rarely pays |
| Treating idiosyncratic as distinctive | The process is genuinely unusual | Ask why it works that way; history is not a reason to encode it |
| No named owner before the build | The question does not arise until handover | Name the owner first; without one the project has a known ending |
| SaaS chosen without modelling growth | Current per-user cost looks reasonable | Model the cost at projected headcount and record volume |
| Custom chosen on ideology | A preference for control, or for not paying subscriptions | Control is worth paying for where requirements are unusual, and not otherwise |
| Skipping configuration and integration | They feel like half-measures | They resolve most cases; skipping them produces builds that reimplement what was already available |
A representative scenario
A composite of situations we see repeatedly; no client detail is included.
A services business asks for a quotation to build a custom operations platform, replacing three systems. The stated reason is that none of them fits how the business works and staff maintain spreadsheets alongside all three.
The review found one workflow that genuinely did not fit — a scheduling method the business had refined over years and which was central to how it competed. The remaining friction came from three systems holding separate versions of the same customer, with the spreadsheets existing to reconcile them.
The work delivered was an integration layer synchronising customer and job records between the three platforms, followed by one custom application covering the scheduling workflow, reading and writing through the existing systems' APIs. The three platforms were kept. The spreadsheets became unnecessary within a fortnight, which was the outcome the original request was really seeking.
The custom component was roughly a fifth of the scope originally quoted, and it covered the part that was actually the business's own.
Decision checklist
- The workflow has been classified: universal, common with variation, genuinely distinctive, or idiosyncratic through history.
- For anything called distinctive, the reason it works that way has been articulated and is a deliberate advantage rather than an inheritance.
- The existing systems have been reconfigured against the current process before being declared inadequate.
- Process disagreements have been resolved, so software is not being asked to settle them.
- Where several systems hold the same data, integration has been costed before replacement.
- SaaS cost has been modelled at projected headcount and record volume, not current.
- Custom cost includes hosting, patching, dependency upgrades and engineering availability, not only the build.
- A named owner exists for anything to be built, and will still be there in a year.
- The exit path is understood for both options: export limits and API quotas on one side, code ownership and documentation on the other.
- Where a build proceeds, the first version covers the single highest-value workflow rather than feature parity with what it replaces.
Frequently asked questions
Is custom software cheaper than SaaS in the long run?
Sometimes, and the comparison that decides it is not the one usually made. A licence fee against a build quote compares the two smallest numbers involved. The realistic comparison is annual cost of ownership across three to five years, where SaaS carries subscription growth with headcount, tier jumps to unlock individual features and paid connectors, while custom software carries hosting, patching, dependency upgrades, framework migrations and engineering availability when something breaks. Custom becomes competitive where per-user or per-record pricing has grown beyond that ownership cost, or where the workflow genuinely cannot be served by anything available.
When should a business build rather than buy?
When the workflow is a source of competitive advantage rather than a process every similar business runs. The test is to ask why the process works the way it does: if the answer describes a deliberate advantage, building may be justified; if the answer is that it has always been that way, the process is idiosyncratic rather than distinctive and building around it encodes an accident permanently. Other legitimate cases are scale breaking the pricing model, a regulatory requirement to control the estate, and an integration burden that has grown larger than the application it surrounds.
What is the middle path between building and buying?
Configuring existing software properly, fixing the underlying process, connecting systems that hold the same data, and building only the specific workflow that genuinely does not fit — as an application that reads and writes through the existing platform's API rather than replacing it. Most requirements are satisfied before the end of that progression. It is the least often proposed option because nobody sells it as a product, and it is the one that resolves the majority of cases, since a large share of custom software requests are really requests for two systems to agree with each other.
What is the biggest risk with custom software?
That nobody owns it. Custom systems most often end not through technical failure but because the person who built or maintained it left, and nobody remaining can modify it with confidence — so it is maintained until it breaks and then replaced under pressure, which is the most expensive possible path. No amount of engineering quality prevents this, because it is an ownership problem rather than a code problem. The mitigations are contractual and documentary: mainstream frameworks rather than unusual ones, source in version control the business owns, reproducible environment setup, and at least one person besides the original author who has successfully deployed a change.
Should you build to capture the last ten per cent a SaaS product does not cover?
Rarely. Rejecting a product that meets ninety per cent of the requirement in order to own the remaining tenth means taking on the maintenance of the whole thing to fix a small part of it. The proportionate answer is to extend through the API — build the specific workflow that does not fit as a separate component that reads and writes to the existing system, leaving that system as the record of truth. This keeps the vendor maintaining ninety per cent of the surface while you own only the part that is genuinely yours, and it remains reversible in a way that a full replacement does not.
How do you know whether a process is genuinely unique?
Ask why it works the way it does, and listen to the shape of the answer rather than its length. A genuinely distinctive process has a reason connected to how the business competes — a pricing method, a scheduling approach, a fulfilment sequence that customers choose you for. An idiosyncratic process has a historical explanation: a decision made by someone who has left, a workaround for a system replaced years ago, or a constraint that no longer exists. Both feel unusual from the inside. Only the first justifies building software around it; encoding the second makes the eventual correction more expensive.
Conclusion
Buying is the right default for almost everything, because almost everything a business does is something other businesses also do, and vendors have solved those problems at a scale no individual company can match. Building is right for the narrow set of workflows that are genuinely your own.
Between those two sits the answer most businesses actually need: the software they already have, configured against the process they actually run, connected to the other systems they already own. It is unglamorous, it is rarely proposed, and it resolves more cases than either alternative.
Sources and further reading
- Custom CRM vs off-the-shelf CRM: which is right for a growing business?— the same reasoning applied to one system in detail
- CRM integration best practices— how to connect systems rather than replace them
- API integration for modern businesses— what an integration commits you to over its lifetime
- n8n workflow automation for modern businesses— the automation step, and when it is enough on its own
Services This Relates To
Written by KYCONNECTS Engineering. Client names are withheld under confidentiality.