Custom software or off-the-shelf? A practical way to decide

"Should we build it or buy it?" is the question every company asks before a system project, and it is usually asked the wrong way round. It sounds like a choice between two products. It is really a choice about where your company's advantage lives.

The short version of this article: buy what everyone needs, build what only you do. The rest is how to tell which is which, what each really costs over several years, and how to avoid the two most expensive mistakes: customising a product until it is a bad custom system, and building a custom system for something a product already does well.

Start with three questions

1. Is this part of how you make money or stand apart? Payroll, accounting, email and a basic CRM are the same in almost every company. A booking flow built around how your clinics work, a pricing engine for how you sell, or a dispatch process nobody else runs are not. The more a process is the reason customers choose you, the more it deserves software shaped around it.

2. Does a product already do most of it? Be honest about "most". Write down the ten things you need, and check each against the product with a real demo and your real data, not a brochure. If it covers eight or nine without bending, buying is likely right. If it covers five and the rest needs "a small customisation", count those customisations as a project of their own.

3. What will this look like in three years? More users, more branches, a new sales channel, an integration with a partner, a new regulation. A tool that fits today can be the wrong shape after two changes, and its price may rise with every user you add.

A table to score it

For each row, mark which way it leans. A pattern appears quickly.

Count the cost over three to five years

Comparing a licence price with a development quote is comparing different things. Put both on the same timeline.

Buying costs

• licences, per user or per month, for each year, with expected price rises
• set-up and migration of your data
• customisation, and each upgrade that has to keep it working
• integrations with your other systems
• training, and time lost while people adapt
• the cost of what the product cannot do

Building costs

• discovery and design
• development, in phases you can stop
• hosting and monitoring
• maintenance, which is not zero: plan a continuing budget for fixes, small changes and updates for as long as the system lives
• your own time as the product owner, which is a real cost and the most often forgotten

Run it for five years. A product that is cheaper in year one can be dearer in year four, and a custom system that looks expensive on day one can be cheaper than licences across a growing team. Neither result is guaranteed, which is why you should do the sum for your case.

The option people forget: both

Many companies get the best result by combining the two: buy the core, build the layer around it. Keep the accounting or HR product, and build the pieces that make it fit you: an integration with your store, a customer portal, a dashboard for the numbers you actually use, an approval flow. The product handles what is common, the custom layer handles what is yours, and neither carries the other's weight.

Red flags when buying

• You would have to change how you work to fit the tool, and the change would hurt.
• The demo shows the happy path, but your exceptions are what cause the trouble.
• It needs many customisations before it fits.
• Exporting your data is hard, limited or costs extra.
• Arabic and right-to-left support is an afterthought.
• Pricing scales with usage in a way that will hurt at your target size.
• The roadmap decides what you can do, and you have no voice in it.

Red flags when building

• Nobody inside the company can own the product and make decisions.
• The requirements are still changing every week.
• You are rebuilding something that is a solved problem.
• There is no budget for maintenance after launch.
• The deadline and the scope do not fit in the same sentence.

How to test either choice cheaply

To test a product, run a two-week pilot with real data and the people who will use it daily. Try your three hardest cases, not the easy ones. Ask how you would get everything out if you left.

To test building, do not start with the whole system. Ask a team to scope and build the one workflow that matters most, as a small first release, and judge both the result and how the team worked. A paid discovery phase that ends in a written plan is a cheap way to find out whether the project is what you think it is.

Questions worth asking

Of a software vendor

• Can I see my own data in a realistic demo?
• How do I export everything, in what format, and at what cost?
• What does a customisation cost, and what happens to it on the next upgrade?
• How does the price change at twice my size?
• Who do I call when something is wrong, and in which language?

Of a development company

• Who will do the work, and will I meet them?
• Who owns the code, the designs and the hosting accounts?
• How will you handle a requirement that changes halfway?
• What is delivered at each stage, and when do I see it?
• What does maintenance after launch include and cost?

A decision checklist

• Name the process, and decide whether it is common or yours.
• Test two products against your ten needs with real data.
• Cost both options on the same five-year timeline, including your own time.
• Consider buying the core and building the layer around it.
• Check Arabic, local rules, integrations and data export before anything else.
• Pilot before you commit, in either direction.

There is no universal answer, and anyone who offers one without knowing your business is selling something. If you are weighing a system project and want an honest outside view of whether to build, buy or combine, tell us about it. Sometimes the useful answer is "buy this and let us build only the part that is yours."