Custom software or an existing package?

Sooner or later every growing SME runs into the limits of its software. The package that was enough five years ago now forces staff into detours, duplicate work and spreadsheets on the side. The reflex is often: let us have something custom built. Sometimes that is the right choice. Often a different existing package is cheaper and faster. Sometimes a better integration between the packages you already have is enough.

This article gives decision rules for making that choice.

When an existing package is the better choice

For processes that run the same way in almost every company, an existing package is almost always the better choice. Think of accounting, payroll, email, calendar, invoicing and a standard CRM. These packages are used by thousands of companies, are adapted to the Belgian VAT rules and are maintained by the supplier.

An existing package is also a good fit when:

your process is still changing and you do not know exactly what it will look like in a year;
you want to start quickly and cannot wait months;
you have no budget for long term maintenance;
the problem lies mainly in how the package has been set up. What the package can do then matters less.

That last point comes up often. A lot of frustration with software is really about poor configuration: the wrong fields, no integrations, no agreements on use. You solve that with a better configuration.

When custom software pays off

Custom software makes sense when the process you build it for sets your company apart from the competition. If the way you plan, calculate or deliver is precisely the reason customers choose you, you do not want that way of working shaped by a standard package.

Other signs that custom software pays off:

you work with three or four packages that together cover one process. Staff copy data from one to the other every day;
no existing package supports a step that is essential for you;
you pay for a large package with many users, while you only use a small part of it;
you need a customer portal or a calculation tool that is specific to your sector.

Custom software does not have to be all or nothing either. Often the best solution is a small piece of custom software that connects existing packages. A simple application for the one step no package handles well can also be enough.

Comparing the costs

A subscription looks cheap because you pay per month. Custom software looks expensive because the costs come up front. A fair comparison looks at the total cost over several years.

For a subscription, you count the monthly price per user times the number of users, over the period you want to use the package. Also factor in price increases, extra modules you will need later and the time staff lose on detours.

For custom software, you count the development, the hosting and the annual maintenance. Custom software needs maintenance after delivery: security updates, adjustments to new versions of connected systems and small improvements. Anyone who does not budget for that ends up after a few years with an application nobody dares to touch.

Then also compare what you do not express in euros. Who owns the data? What happens if the package supplier stops or doubles its prices? What if the developer of your custom software is no longer available? With custom software, always ask for the source code and the documentation to become your property.

A prototype first

The biggest risks with custom software are a misunderstood problem and a project that keeps growing. A prototype limits both.

A prototype is a simple, working version of the core of the application. It does one thing: solve the most important problem for a small group of users. It may look plain and have few features. What matters is that it is really used, with real data.

After a few weeks you know three things that were unclear beforehand: whether the problem is really solved, which features staff miss and which they never use. Based on that you decide whether to keep building, adjust course or stop. Stopping after a prototype is the cheapest way to avoid an expensive mistake.

Maintenance and ownership

Software is never finished. For a package, the supplier handles that. For custom software you have to arrange it yourself. Make agreements about this in advance:

who maintains the application and within what time errors are fixed;
how often security updates take place;
where the data is stored and how it is backed up;
how the application is documented, so that another developer can take it over.

What you can do now

Make a list of the tasks where staff currently retype data between systems. That is where most of the gain lies, with or without custom software.
Check whether the problem lies in the package itself or in the way it has been set up.
If you are considering custom software, describe the one problem a prototype must solve and how you will measure after a few weeks whether it has succeeded.

From Ghent we build custom software for SMEs across Flanders, always starting with a prototype, while hetdesignbureau.be takes care of the websites and the visual side of customer portals.