Custom software or off-the-shelf: how to choose

You need software for a process that currently lives in spreadsheets and email. There is a package that does most of it, and there is the option of having it built. That choice is rarely about technology. It is about how much of your own way of working you are willing to give up, and what that is worth.

What are you actually choosing between?

An off-the-shelf package is someone else's way of working, neatly packaged and worn in by thousands of companies. You get updates, documentation and people in the market who know how to use it. The flip side is that you adapt to the package.

Custom software is your way of working, captured in code. You decide what it does and what it doesn't. The flip side is that you own all of it: maintenance, updates, security and the knowledge to change it. What that involves is covered under custom software.

So the question isn't which of the two is better. It is which part of your process is distinctive enough to capture yourself.

Why does the choice usually stall?

Three patterns come up again and again.

• The demo: you see the package at its best, with clean data and none of your exceptions. You judge the demo, but what you get is your own records.
• The requirements list: a hundred lines, ninety of which every package meets. The ten that really matter get lost in the crowd.
• The edge case: one customer with a special pricing deal becomes the reason to build everything, while it covers only a few per cent of orders.

All three come from the same gap. There is no description of the process as it really runs today, so the choice is made on gut feeling.

Step 1: write down what the process really does now

Walk through the process once with the people who do the work, not the people who once documented it. For each step, note who does it, where the data comes from, how long it takes and how often it goes wrong.

Above all, look for the steps that aren't in the manual. The quick call to the planner, the spreadsheet tab next to the system, the email someone forwards because the system can't do it. That is exactly where the difference between a package and your own software lies.

Step 2: separate the standard from the distinctive

Put every step in one of two columns. Standard means every company in your sector does it roughly this way. Distinctive means it is the reason customers choose you, or it follows from an agreement you can't change.

Accounting, payroll and time tracking are almost always standard. There are good packages for them, and you won't beat them. Your pricing structure, your planning logic or the way you build up a case file can be distinctive.

If almost everything is standard, buy. If the distinctive part sits right at the heart of your revenue, building your own is defensible.

Step 3: test packages against your exceptions

Don't go by the feature list. Give the supplier three real cases from your own records, including the awkward ones, and ask them to run those in the demo environment. Not describe them. Run them.

Be wary of the answer that something is possible with a small customisation. Ask who builds that customisation, what it costs and what happens to it at the next package update. A package with twenty customisations costs more to maintain than your own software.

Step 4: calculate over five years, not one

Put both options side by side over five years. For a package: licences per user, implementation, integrations, customisations, migrating your data and the hours your own people put in. For custom software: build, hosting, maintenance, further development and the risk that the knowledge stays with one supplier.

Per-user licences are the cost most often underestimated. They grow with your headcount, even when usage doesn't. Indicative prices for custom software are on what a web application costs. What your current manual work costs you can be worked out under the cost of manual work.

Include the return in the same sum. What that model looks like is set out in calculating the business case. The same structure works for automation without AI.

What to look for in an off-the-shelf package

Three things that only become visible after you sign.

• Your data: can you get to it without the supplier, via an export or an API, and does it include every field or only the basics?
• The integrations: is there a connection to your accounting and your online store, and which data goes across? What is possible per package is set out under integrations.
• The release policy: how often are updates released, and what happens to your customisations when they are?

When is building your own a bad idea?

When nobody in your company makes the decisions about the software. Custom software without an owner becomes, within two years, a system nobody dares to touch.

Also when the process still changes every month. You would be fixing in code something that isn't settled yet. And when the volume is small: fifteen tasks a week rarely justify a system of your own.

Is there a middle way?

Yes, and it is the one most often chosen. You use packages for the standard work and build only the distinctive part yourself. That part talks to the rest through integrations. What such a connection costs is set out in what an integration costs.

If you don't yet know which part that should be, that is exactly what the AI Opportunity Audit works out: where in your process work gets stuck, and whether a package, an integration or custom software is the answer.