Business software 3 min read

Custom ERP or off-the-shelf SaaS? A decision framework

When ready-made ERP or SaaS software is the right choice, when custom business software pays off, and why the best answer is often a mix of both.

Every growing company eventually reaches the same point: spreadsheets and disconnected apps stop keeping up. The next step is usually presented as a simple choice: buy an ERP or SaaS product, or have custom software built. In practice, the right answer is often both, each in the right place.

(An ERP is software that manages a company’s core operations, such as sales, stock, purchasing and accounting. SaaS means software you rent online by subscription.)

The question behind the question

The real question is not “build or buy” but: where does your business need to work differently from others?

  • Processes that are the same in every company, such as accounting, payroll, email or basic customer management, are standard. Buy them.
  • Processes that give you an edge over your competitors, such as how you set prices, plan, deliver or serve customers, are where forcing yourself into someone else’s software costs you the most.

When ready-made software wins

  • Your processes follow industry standards and you are happy to adopt the tool’s way of working.
  • You need to be up and running in weeks, not months.
  • The vendor is well established, with a clear roadmap, data export options and an API.
  • Licence costs stay reasonable as you add users and locations.

When custom software pays off

  • Your way of working is a real competitive advantage, and the tool would force you to give it up.
  • You pay for large software suites while using a fraction of their features, with workarounds on top.
  • You need systems that do not talk to each other to share data closely.
  • You need something the local market does not offer well, such as offline use, Arabic and French interfaces, local payment methods or local compliance rules.

Compare the total cost, not the price tag

Build a simple five-year comparison:

Cost itemReady-made softwareCustom software
Licences and subscriptionsper user, per yearnone (hosting only)
Setup and configurationmoderateincluded in the build
Customisation and workaroundsoften underestimatedlow
Connections to other toolsdepends on the vendor’s APIdesigned in
Maintenance and new featuresthe vendor’s roadmapyour roadmap, your budget
Cost of leavingdata export, retraininglow if you own the code

The line that surprises most companies is workarounds: the hours staff spend adapting the process to the tool, every day, for years.

The mix that usually works best

Most successful setups combine:

  1. Standard SaaS for accounting, email and collaboration.
  2. A custom core for the work that sets you apart: operations, planning, field work, pricing.
  3. Connections that keep data consistent between the two, so nobody types anything twice.

This puts licences and custom code where each brings the most value.

Questions to ask before deciding

  • Which three processes, if they ran perfectly, would improve our results the most?
  • How much time does the team spend today on workarounds and double entry?
  • Can we export all our data from the tool we are considering, in a usable format?
  • Who will own the system and decide its future in two years’ time?

If you are weighing this decision, an independent architecture review can help. We are just as happy to recommend a SaaS product when it is the better answer.

Frequently asked questions

Custom ERP or off-the-shelf SaaS? A decision framework

Is a custom ERP more expensive than SaaS?

At the start, almost always. Over five years, it depends on the licence cost per user, how much the business has to adapt to fit the tool, and the work needed to connect it to other systems. Comparing the total cost over several years is the only fair basis.

Can we start with SaaS and move to custom software later?

Yes, and it is often a wise choice. Make sure you can export your data in a usable format and that connections to other tools go through APIs you control, so a later move is a planned migration rather than a rescue.