When custom development costs less than an off-the-shelf product

Why can’t you compare them by licence price?

Because on one side is the price of the software, and on the other the price of the software plus the cost of the company adapting to it. That second item appears on no quote, even though the company pays it: in training, in entering data twice, in a spreadsheet kept alongside the system, and in the time of people working out how to get round something that does not suit them.

So it is the total that decides. An off-the-shelf product wins where the process can be adapted and bending it costs nothing. Custom development wins where adapting the process would cost more than the software itself, which tends to be precisely in whatever sets the company apart in its market.

What are you actually paying for with custom development?

For the smaller part. Sign-in, permissions, records, printing and integration interfaces are ready-made in the core, so they are not programmed again; what is developed is the business logic that no off-the-shelf product has. In a typical project this works out at roughly eighty per cent ready-made parts and twenty per cent custom development, and only the specification will show what the ratio will be in your case.

This is also the answer to the question of why custom development can cost less than buying an off-the-shelf product, which sounds like a contradiction. The comparison is not between development from scratch and a boxed product, but between a boxed product and an extension built on a foundation that is already in place and paid for. The Element platform, on which that core runs, has existed since 2020, and most of our applications are built on it.

When does an off-the-shelf product win?

Whenever your process is essentially standard. An off-the-shelf product carries the experience of the operations that already use it, and its way of working is often better than the one the company is used to; holding on to your own variant just because it is your own does not pay off in that case. Four signs decide it:

• Your rules can be described so that even an outsider understands them, and they do not come with dozens of exceptions.
• Companies with similar operations already use the product, without having had to change their line of business for it.
• Time is decisive: you need to be up and running in weeks, not months.
• Nobody in the company can say exactly how your work differs from your competitors’.

The last point tends to be the most useful and also the most uncomfortable. When the question “what can’t the standard do for us?” gets a vague answer (“we want it our way”), that is usually a sign that custom work is not needed; it is just that nobody wants to change a habit.

How can you tell that the standard does not fit you?

By what exists in the company alongside the system. A spreadsheet into which data from the system is copied because the system is missing one column. A shared document holding whatever did not fit into the form. People who enter the same thing twice so that it matches on both sides.

These workarounds are measurable and have a cost in hours. Once you add them up for a year, you have a figure you can compare a development quote against. Without it, the decision is made on impression, and impression usually favours the option that is cheaper in the first year.

What costs more than expected with custom software?

Life after go-live. A custom application has no vendor developing it for you, so every change in the law, every integration and every new feature is a separate order. You can plan for this, but it has to be in the budget from the outset; otherwise delivery will use it up and nothing will be left for further development.

The second item is dependence on the supplier, and it is fair to ask about it before you sign. Where the data will live: on your premises or as SaaS. Who operates and develops the application. What happens when the cooperation ends: what you receive, who is able to take over operation, and whether the core is built on common components that can be replaced or on something only one company in the world knows how to work with.

When is the price decided?

Before any programming starts, and that is the part worth checking in a quote. First a workshop on how you work today and where software gets in your way, which establishes what the application should and should not do. Then written requirements with an outline quote, so you decide on scope and price before the first line of code is written.

Only then does development begin, and in parts: you go through each finished module in a test run on your own data. The point is not that this looks modern, but when the difference between what you meant and what is written in the specification comes to light. With delivery in parts it shows up the same week; with work handed over at the end, only when nothing can be done about it any more.

How such an application comes into being and what is ready-made in the core is described under custom application development and the Element platform; both sit in the Custom development category. The same decision on a smaller scale, a ready-made solution versus a designed one, is also discussed in the article on warehouse systems.