Menu

Insight

Custom software or SaaS: when does building your own start to make sense?

22 Jul 2026

  • Software strategy
  • Custom software
  • SaaS

Buying software is usually the right first move. A mature SaaS product can give a team years of accumulated product work for a monthly fee. It is hard for a custom build to beat that when the job is common and the way you do it is not commercially important.

The decision changes when the business spends more time working around the product than working in it.

Start with the cost of the workaround

Subscription price is the visible part of SaaS cost. The larger part may be spread across the people using it:

  • staff copying information into another system because the integration stops halfway;
  • managers maintaining a parallel spreadsheet because the reports do not answer the real question;
  • customer requests handled by email because the portal cannot represent an exception;
  • an experienced employee checking every case because the workflow cannot encode what they know.

None of these automatically justifies custom software. They are evidence that the current tool does not cover the whole job. Put a realistic number on that gap before comparing options.

If six people each lose two hours a week, include the cost of those hours. If a workaround delays invoicing, estimate the cash-flow effect. If customers abandon an awkward ordering flow, look at what that means for repeat business. The estimate will not be perfect. It only needs to be honest enough to show whether the problem is worth engineering effort.

Stay with SaaS when the process is ordinary

Payroll, accounting, email, basic CRM, and project management are poor candidates for a custom build in most companies. The compliance burden and feature depth of established products are valuable, even if the interface is not exactly how the team would have designed it.

It can also be cheaper to change the process. If the difference between your workflow and the standard product exists mainly because “we have always done it this way”, software should not preserve it without question.

An integration or a small extension may solve the problem without replacing anything. A customer portal can sit in front of an ERP. A focused operations screen can use data from several systems while each remains responsible for what it already does well.

Build when the process is part of the advantage

Custom software becomes easier to justify when the workflow is one of the reasons customers choose the business, or when it determines how efficiently the business can deliver.

A logistics company with a specialised fulfilment model may not want its operations reduced to the nearest WMS template. A hospitality group may need a service workflow that crosses reservations, guest history, and internal coordination in a way no single product covers. A subscription business may need control over entitlement and branded delivery that a marketplace product will never give it.

There is another signal: the business is already building software unofficially. Large spreadsheets, linked databases, automation scripts, and heavily customised SaaS setups are all forms of development. They simply distribute the work across tools that were not designed to become the core system.

Compare five years, not the first release

Custom software brings its own costs. It needs maintenance, security updates, hosting, support, and people who understand it. Requirements will change after users touch the real system. A responsible business case includes that life after launch.

The useful comparison is not “€200 per month versus a €60,000 project”. It is the expected cost and commercial effect of both paths over several years:

  • licences and implementation;
  • manual work that remains;
  • revenue or service improvements the software makes possible;
  • the cost of future changes;
  • the risk of depending on a vendor, and the different risk of owning a system.

Sometimes SaaS still wins by a wide margin. Sometimes a narrow custom layer is enough. The best custom-software projects usually begin after those cheaper answers have been considered, not before.