Comparison

Custom software, a package, or low-code: which one?

The three routes compared on cost, speed, ownership, and where each one breaks down, including when the honest answer is the cheapest option.

Published 8 August 2026

There are three ways to get business software: buy an existing package, build on a low-code platform, or have custom software developed. They are often argued about as if one wins, but they solve different problems. This comparison sets out where each fits, and where each one breaks down.

The three routes side by side

	Package	Low-code	Custom
Speed	Days to weeks	Weeks	Weeks to months
Upfront cost	Low, per user per month	Low to moderate	High, one-off
Cost after three years	Grows with your headcount	Grows, plus platform fees	Flat, maintenance only
Fit to your process	You adapt to the package	Reasonable, within platform limits	Complete
Ownership	None, you rent	Limited, tied to the platform	Source and data are yours
Cost of leaving	Migrating your data	Usually a rebuild	Nothing, you already hold it
Where it breaks	On the work that sets you apart	On volume, branching logic, debugging	On work that runs the same everywhere

When a package wins

For anything that works at your company the way it works everywhere. Accounting, payroll, email, storage, time tracking: no competitive advantage lives there, companies devote their whole existence to it, and the maintenance is shared across thousands of customers. Building custom here means paying alone for something that comes free elsewhere.

When low-code is the right middle step

Low-code is strong when you need something working quickly for a defined group and are not yet sure it will stay. An internal request form with approval steps, a simple scheduling tool for one department. It breaks down once a lot of data flows through, the logic branches, or you want to trace why something failed. At that point you spend more time working around the platform than it saved you.

When custom pays for itself

On the work your company does differently from the rest, which is often exactly why customers choose you. A schedule that accounts for your machines, a pricing structure nobody else uses, an inspection process specific to your industry. Also when a package costs money structurally in workarounds: if three people each spend a day a week retyping, the arithmetic is usually quick.

The combination that most often works best

In practice it is rarely one of the three. The most common good answer: keep the package for what it is good at and build custom around the bottleneck, with an integration between them. Accounting stays in the package; quote intake and scheduling move to a system that does follow your process. That costs a fraction of replacing everything and delivers most of the gain.

How to work it out for yourself

Count the hours currently lost to workarounds per week, measured rather than estimated.
Set five years of licence fees beside it, including the growth of your team.
Add what the migration you will eventually have to do anyway would cost.
Compare that total against build cost plus maintenance for custom.
Weigh what it is worth to be able to leave without starting over.

Frequently asked

Can I start with low-code and move to custom later?

You can, but expect a rebuild rather than a migration. What carries over is worth more than the code: you will know exactly which exceptions live in the process and what people actually use. As a deliberate first step that is defensible; as a saving it usually is not.

Isn't custom always more expensive?

Upfront, almost always. Over five years, often not. A package charges per user per month and so grows with your headcount; custom is a one-off investment with maintenance after. Where the crossover sits depends on how many people use it and how much time the workarounds cost today.

What if our process changes in two years?

That is the argument for custom, provided it is built well. With a package you wait for the vendor to build it, or you work around it again. With your own software you decide when it changes. The condition is that the foundation is sound, otherwise changing it is expensive there too.

How do I know whether my process really differs?

Have someone who knows the package well lay your process into it without workarounds. If that works, you differ less than you thought and a package is the right answer. If it stalls on the same three points every time, you know exactly what the custom work has to solve.