Custom Software or SaaS? A Framework for Deciding

The question is usually asked backwards

The conversation tends to arrive in the same shape: should we buy this product, or build something of our own? Framed that way it is a question about technology, and it gets answered with preferences — the operations lead has used the product before, the technical adviser would rather own the stack, and whoever controls the budget picks between two positions that were never really compared.

The more useful question is narrower. Not “should we build custom software?” but “where does owning this software create enough value to justify the cost and complexity of owning it?” Ownership is not a one-off: it is a commitment to keep paying for something in exchange for control over it. That trade is excellent in some parts of a business and indefensible in others.

It is also not a single decision. A company does not become a custom software company or a SaaS company; it makes this call separately for a dozen workflows — invoicing, scheduling, support, fulfilment, reporting — and the right answer differs across them. Most healthy setups are mostly bought, with a small owned core carrying the work nobody else does the same way.

What follows is how to make that call one workflow at a time — including the cases where the honest answer is that neither option is appropriate yet.

Start with the problem, not the software

Most build-versus-buy conversations start at the end. There is already a shortlist of products, or a proposal for a system, which means a solution is being evaluated before the problem has been written down. The cost of that is invisible at the time and obvious a year later, when the company is running a tool that solved a problem it turned out not to have.

Four things need establishing first, and none of them requires a technology decision. What the workflow actually is, including the informal steps — the spreadsheet someone maintains on the side, the re-keying between two systems that never made it into the process document. Where it breaks, and who absorbs the breakage. What that breakage costs, in hours, errors and delayed revenue. And whether the workflow is something customers choose you for, or plumbing that has to work.

This is also where a good number of custom software requests dissolve. A company convinced it needs a bespoke CRM often has a data problem and an accountability problem underneath: three systems disagree about who owns an account, and nobody is responsible for reconciling them. New software settles neither question. It encodes the confusion and charges for the privilege.

What is the workflow, including the steps nobody documented?
Where does it break, and who absorbs the breakage today?
What does that cost per month — in hours, errors, delays and lost revenue?
Is this workflow a reason customers choose us, or is it plumbing?
If we changed nothing for another year, what would that cost?

When buying is the better decision

For most workflows in most businesses, buying wins, and it is not close. Payroll, accounting, email, support ticketing, standard CRM — these are solved problems, and a vendor amortises the cost of solving them across thousands of customers. No internal team matches that arithmetic on a workflow that looks the same everywhere.

Speed is the other half of it. A configured product is running in weeks, at a price you can read off a page, and a wrong choice costs a subscription and a migration rather than two quarters of development budget. That bounded downside is worth more than it looks for a decision made under uncertainty — which most of these are.

Mature products also carry the unglamorous eighty per cent nobody budgets for when they build: permissions and roles, audit trails, exports, mobile access, single sign-on, backups, an uptime record, and a support team that answers when something breaks at month end.

Choosing SaaS is not the lesser decision. Buying the commodity is precisely how a company affords to build the one thing that is genuinely its own.

The workflow is essentially the same as it is at comparable companies.
Doing it better than average is not why customers choose you.
Implementation speed matters more than control.
Customisation needs stop at configuration — fields, roles, templates, rules.
The vendor’s roadmap is heading somewhere you can live with.
If you had to leave in three years, you could get your data out and move.

When custom software starts to make sense

Custom software earns its place on evidence rather than on the promise of flexibility, and the signals are already visible in how the business runs.

The clearest is the accumulation of workarounds. Every export into a spreadsheet, every field used for something other than its name, every rule the team follows because the tool cannot express it — each is a small permanent tax, and together they measure how far the product sits from the actual process. When that tax is large and recurring, it becomes comparable with the cost of building something that does not levy it.

The second is orchestration. A single system rarely needs replacing; the problem is usually that four of them each hold part of the truth and a person is the integration layer, moving records between them and resolving disagreements by hand. That role is expensive, error-prone and impossible to scale, and it is the shape of problem a custom layer solves well.

The third is differentiation. If the process is a reason customers choose you — how you route jobs, how you price, how you deliver faster than the alternative — then renting it means your advantage is a configuration a competitor can subscribe to on the same terms tomorrow. Owning the software is one of the few ways to keep an operational advantage from being copied at that speed.

Scale finishes the argument rather than starting it: friction that costs a little per transaction becomes a real number at volume, and per-seat pricing works against you as you grow — but only once the volume is real, never on projected usage.

The products would require you to change the process, not the settings.
People are the integration layer between systems that ought to talk.
The workflow is part of why customers choose you, not just how work gets done.
The cost of the workaround scales with volume, and volume is growing.
You need control over data or roadmap for a reason you can state.
The system will still matter in three years, and someone will own it.

A framework for weighing the decision

The framework below is nine dimensions. Score each from 1 to 5 for the specific workflow under discussion — not for the company as a whole, and not for a category of software. The value is not in the total; it is that the dimensions get argued separately, with evidence, instead of collapsing into a single opinion held by whoever is most senior in the room.

Strategic differentiation — if a competitor bought the same product tomorrow, how much of your advantage would disappear?
Workflow uniqueness — how much of the process would have to change to fit the product, and would that change be an improvement or a loss?
Integration complexity — how many systems have to agree, and who reconciles them today?
Expected usage and scale — how many people and transactions, now and in twenty-four months?
Economic impact — what does the friction cost per month, in numbers you can defend?
Required control — what happens if pricing changes, the vendor is acquired, or the feature you depend on is deprecated?
Time-to-value — what does a six-month wait cost, against two weeks of configuration?
Internal capability — who owns this after launch, and is that a named commitment or an assumption?
Long-term ownership cost — can you fund years two and three, not only the build?

How to read the scores

The first six dimensions argue for building as they rise. The last three are constraints rather than justifications: heavy time pressure, no internal owner, or no budget beyond the build does not make buying more attractive in principle — it makes building unaffordable in practice, whatever the first six say.

Three readings come up repeatedly. If differentiation and workflow uniqueness are both low, stop there: buy the product, configure it, and spend the attention somewhere it earns more. If both are high and the economic impact is high, building is likely to be worth it, provided the constraints allow. And if the six are split — high on integration and economics, low on differentiation — the answer is usually neither pure option.

There is one more use for the exercise, and it is the one people skip. If you cannot put a number on economic impact, or name who will own the system after launch, the decision is not ready to be made — a finding rather than a failure, and far cheaper to reach in a scoring conversation than in month four of a build.

The cost that gets left out

Development cost is the part of custom software that appears in the proposal, and it is not the part that decides whether the decision was right. A system that runs is a system somebody maintains.

Past the build there is hosting, dependency upgrades, security patching, monitoring and the response when monitoring fires, backups, support for the people using it, the documentation that keeps it transferable, and the continuing development any system in active use requires. None of it is optional and all of it is annual. Where there is no budget line for year two, the honest conclusion is that the system should not be built in year one.

Subscriptions compound in their own way. Per-seat pricing scales with headcount rather than with value received, and the capability you actually needed is often in the tier above or sold as an add-on. Then there is implementation, data migration, the connectors that keep the product talking to everything else, and the labour of the workarounds it forces. Switching cost is the one that moves: it grows with every month of data and process you place inside the product, which is why a tool that was a good decision in year one can be an expensive one by year four without anything about it having changed.

Compare over one horizon — three to five years is usually enough — and keep a third column for changing nothing, since the status quo has a running cost too, and it is the one the business is already paying.

Build column: development, infrastructure, security, monitoring, support, documentation, upgrades, continuing development.
Buy column: subscriptions at projected headcount, tier changes, add-ons, implementation, migration, integrations, workarounds.
Both columns: the cost of the transition itself, and of leaving in three years.
Third column: what the current way of working costs over the same period.

Most good answers are hybrids

The binary framing is largely an artefact of who is selling: vendors compare themselves against building, agencies compare themselves against buying. Operators do both, and what the good arrangements share is a refusal to build anything that can be bought, and a refusal to rent the part of the operation that makes the business worth choosing.

Hybrids fail in a predictable way, so they need one rule. For every important entity — customer, order, invoice, job — decide which system holds the truth, and make every other system a reader of it. The custom layer should depend on documented, stable interfaces, and the seam between bought and built should be as thin as you can make it. Without that discipline a hybrid becomes two systems that disagree, which is worse than either option alone.

Our own product is built on that split. TanCerca is a marketplace with merchant tooling, delivery coordination and an operational layer we designed and built, running on payment and cloud infrastructure we did not build and had no reason to. The custom part is the part that had to match how local merchants and couriers work.

SaaS for accounting, payroll and email; custom for the workflow the business runs on.
An existing CRM as the record of customers, with a custom operational layer for the pipeline specific to you.
SaaS systems of record, with a custom reporting surface for what the built-in dashboards will not answer.
Existing communication tools, with custom orchestration deciding what happens, when, and to whom.

A sequence you can run this month

Turning any of this into a decision takes a sequence, and it is short enough to run in a couple of weeks without stopping the business.

Step three is where most of the value sits. Companies routinely mistake familiarity for uniqueness: a process is not distinctive because it is yours, but because doing it differently produces a different result for the customer. Honesty there is what keeps a build proposal from becoming an expensive way to preserve a habit.

Waiting is a real outcome, not a failure to decide. If the problem is undefined, if the process still changes every few weeks, if the volume is too low for the friction to cost anything meaningful, or if the process itself is broken, neither buying nor building will help — automating a broken process produces the same mess, faster and harder to see. Stabilise the workflow by hand for a quarter, instrument it enough to know what it costs, and revisit with numbers. A deliberate decision to wait, with a date on it, is a decision. Drifting is not.

Define the operational problem in writing, including the informal steps.
Quantify what it costs today — hours, errors, delays, revenue.
Separate what is genuinely unique about the process from what is merely familiar.
Evaluate real SaaS options against the workflow, not against a feature list.
Document the gaps and the workarounds each option would require.
Estimate total cost of ownership for build, buy and status quo over one horizon.
Score the nine dimensions, and argue the ones you disagree about.
Decide: buy, build, combine — or wait, with a date to revisit.

Build only what is worth owning

The principle underneath all of this is easy to state and harder to apply: build the parts of your digital infrastructure that create meaningful strategic or economic value, and buy the parts that do not.

The two failure modes are symmetrical. Building the commodity is expensive and invisible — a custom invoicing system that does what a subscription does, with a maintenance burden attached and nothing gained. Renting the differentiator is cheap now and capped later: the operation runs inside somebody else’s product, at their pace, with a ceiling set by their roadmap. The first mistake shows up in the budget, the second in the strategy, and it is much harder to reverse.

Most companies end up mostly bought, with a small custom core. The discipline is in keeping that core small and making sure it is the right part.

Where the answer is genuinely unclear, the useful next step is not a proposal. It is an hour with the workflow written down, the numbers on the table and the real alternatives compared — which is how our software development work starts, and often enough it ends with a recommendation to buy something and get on with the business.