Custom software or an off-the-shelf package: how to make the choice

Sooner or later every growing SME faces the same question: do we buy an off-the-shelf package, or do we have software built to measure? The package vendor says their solution does everything. The developer says custom software fits perfectly. Both are right, and both are leaving something out.

This article is not a plea for custom software. We build it, but we tell companies at least as often that they are better off buying a package. Below is the trade-off as we make it ourselves, including the cases where you do not need us.

The terms first

Off-the-shelf software is a package built for many companies at once. You pay a licence, usually per user per month, and you get what everyone gets. Adjustments happen through settings, modules or a partner who configures the package.

Custom software is built for your company, around your process. You pay for the development and then for maintenance. What the software does is up to you.

The difference is not in quality or technology. It is in the question of who adapts to whom: you to the software, or the software to you.

When off-the-shelf is the right choice

Let us be honest about this: for most processes in your company, a standard package is the best choice.

Your process is not distinctive. Accounting, payroll, email, a calendar, standard CRM for a classic sales process. Here you do the same as a thousand other companies, and that is fine. Excellent software exists for it, proven and affordable.

You want to start tomorrow. A package is up in days or weeks. Custom software takes months. If speed is the most important criterion, the package wins.

You do not know exactly what you need yet. A standard package forces you into a structure, and sometimes that is good. The package has thought about what works. If your process has not crystallised yet, you learn from that structure.

The number of users is small. Licence fees per user hurt at fifty users, not at five.

There is a package made for your sector. Industry software for garages, pharmacies, law firms or installers often covers eighty percent of what you need. That is hard to beat.

When custom software pays off

Custom software makes sense in the places where your way of working is exactly what makes the difference, or where a package forces you to work differently than you want.

Your process is your edge. You plan, calculate or deliver differently from your competitors, and customers choose you because of it. A standard package sands that difference away.

You are bending the package. Recognise this: a mandatory field you do not use and always fill with a dash, an Excel file next to the package, a "workaround" everyone knows? Every detour is a signal that the software does not fit. Three detours are a pattern.

You need integrations the package does not offer. Your ERP has to talk to your planning, your web shop to your stock, your work orders to your invoicing. Standard packages integrate with what the vendor chose. Custom software integrates with what you have. More on that on our page about API integrations.

The licence cost adds up. Fifty users times a monthly licence, every year again, plus the paid modules you turned out to need along the way. Work that out over five years and put it next to a one-off build plus maintenance.

You want control. Over your data, your process and the direction of the software. With a package you rent, and if the vendor stops, changes prices or changes terms, you are stuck. With custom software the application is built exclusively for you and you decide what gets added. How ownership and licensing are arranged exactly is something you settle in the contract with your development partner.

The middle road that wins most often

In practice the choice is rarely black and white. The pattern we build most, and that works best for most SMEs, is this: a standard package as the core, with custom software around it.

Your accounting stays in your accounting package. Your ERP remains your ERP. But the schedule that lived in Excel, the customer portal your ERP does not have, the app for the shop floor, the link between your web shop and your stock: that becomes custom software, built on top of what is already there.

That way you do not pay to rebuild what already works, and you are not stuck with the limits of the package in the places where it pinches. An example of that approach is SolveIT for Samoco: the existing tools for time tracking and safety stayed, but one platform went on top that brings everything together and keeps it in sync.

Custom and off-the-shelf side by side

The mistakes we see most often

Choosing based on the demo. In the demo every package can do everything. Ask to run through your own process, with your own exceptions. That is the moment when "that works via a workaround" appears.

Underestimating the cost of adapting the package. "Standard" rarely means you have nothing to do. Configuration, consultancy, extra modules and training add up. Ask for the total cost over three years, not the licence price.

Having custom software built for something that exists. Your own accounting package, your own mail tool, your own CRM for a classic sales process. That is burning money. A good development partner will say so too.

Starting too big. Digitising the whole company in one go. Start with the process that hurts most, build that, and expand when it works.

No owner inside the company. Software, custom or standard, needs someone who decides what it should do. Without that person every project dies a quiet death.

Five questions to make the choice yourself

Answer them honestly, preferably together with the people who would use the software every day.

1. Do we do this process differently from other companies, and does that difference matter to our customers? No: package. Yes: read on.
2. How many detours do we use today? Excel files next to the system, fields we misuse, steps we do outside the software. More than three: the package does not fit.
3. What does our current system cost over five years, everything included? Licences, modules, consultancy, and the hours we lose to the detours from question two.
4. Which systems need to talk to each other, and can they today? Every manual hand-over between two systems is a candidate for an integration or for custom software.
5. How are ownership and licensing arranged, and can we get our data out? Ask the package vendor and the development partner alike. If the answer is unclear, that is an answer in itself.

How we make that trade-off

Every project with us starts with a conversation about your process, not about software. In that conversation we also say when custom software is not a good idea, and that happens regularly. If a package exists that fits, you will hear it from us.

If custom software does turn out to be the right choice, our page on custom software explains how such a project runs, from intake to delivery, and what to expect in terms of timeline and investment.