Custom software or low-code? How to tell which your business actually needs

There is a moment most growing businesses reach with their software. The spreadsheet that ran the job board for years has started to creak. The off-the-shelf package nearly fits, but not quite, and the workaround everyone has agreed to use is held together with goodwill and a shared inbox. Someone, usually the owner, starts wondering whether it is time to have something built properly.

Then comes the harder question. Should that something be a custom application, written from scratch for the business, or should it be put together on a low-code platform such as Microsoft Power Apps? The two routes cost different amounts, take different lengths of time, and age very differently. Picking the wrong one is expensive in a way that does not show up for a year or two, which is exactly when it is most awkward to change course.

This article is about telling the two apart before the money is spent. It does not assume any technical background. By the end, the aim is for an owner or a manager to be able to look at a particular problem and say, with reasonable confidence, “this is a low-code job” or “this one needs building”.

First, what the two words actually mean

A quick definition of each, because the terms get used loosely.

Custom software is an application written specifically for one business, in general-purpose programming languages, by developers. Think of it as a building designed by an architect for a particular plot and a particular use. It can be made to do almost anything, because nothing about it is fixed in advance. That freedom is also its cost: someone has to design, build, test, and then keep maintaining every part of it.

Low-code is a way of building applications using a platform that supplies most of the moving parts already, so that a working app is assembled largely through configuration and visual design rather than written line by line. Microsoft Power Apps is the example most UK SMEs meet first, often because it comes bundled with the Microsoft 365 subscription they already pay for. The platform handles the plumbing (the database, the user logins, the screens on a phone or a browser) so that a smaller amount of effort produces a usable app far more quickly. A Microsoft-commissioned study by Forrester found professional developers cut application build time by around half when using Power Apps 7. The trade-off is that the platform also sets the boundaries of what is easy, and of what is possible at all.

It is worth saying plainly that this is not a fringe choice on either side. The analyst firm Gartner forecasts the low-code market to keep growing strongly through the rest of the decade, reaching tens of billions of dollars 8. Low-code is now a normal, sensible way to build a great many business applications. The skill is in knowing which great many, and which to leave to custom development.

The one question that settles most cases

Before getting into cost or scale, there is a single question that decides the matter more often than any other. It comes from the software writer Martin Fowler, and it is worth keeping in the front of the mind for the whole decision.

Is the thing being built part of what makes the business different from its competitors, or is it just something the business needs in order to operate?

Fowler calls this the difference between strategic and utility software 1. A strategic capability is one where doing it differently, or better, than rivals is part of the point. A utility capability is necessary but not a differentiator: every business in the sector has roughly the same need, and there is no advantage in having a unique version of it.

The guidance that follows from this is clear. For a strategic capability, lean towards custom, because the whole value lies in it not being the same generic thing a competitor could buy or assemble. For a utility capability, lean towards low-code or an off-the-shelf product, because there is nothing to be gained by spending heavily to build from scratch what the platform will hand over almost for free.

A worked example. A field-service firm that wants an internal app for engineers to log which parts they used on a job is building a utility. Useful, worth doing, but every similar firm needs the same thing and none of them competes on the quality of their parts-logging screen. That is a low-code job. The same firm, if it had invented a genuinely novel way of scheduling and pricing jobs that won it work its rivals could not match, would be looking at a strategic capability, and forcing that onto a low-code platform would mean handing its one real advantage to the limits of someone else’s product.

Most internal business apps, it turns out, are utilities. That is the honest reason low-code suits so many SME projects: most of what a business needs software to do is not the part that makes it special.

The 10% that low-code cannot reach

Even on a utility job, low-code has a well-known failure pattern, and it is worth understanding because it catches people out.

The platform gets the first 80 to 90 per cent of a build done remarkably fast. The screens appear, the data saves, the app runs on a phone within days. The trouble arrives with the last slice. When a requirement falls outside what the platform was designed to do, there is often no way to reach underneath the platform and make it behave. Engineers at ThoughtWorks describe this as the “ten-percent trap”: the final tenth of the work can turn out to be not merely hard but impossible, because the very abstraction that made the first 90 per cent quick is also what blocks the rest 3.

This is not a reason to avoid low-code. It is a reason to be honest, early, about whether the build has any of that awkward last 10 per cent in it. A simple internal tool with predictable, well-understood requirements almost certainly does not. An app with unusual logic, a tricky integration with an old system, or a feature nobody else has tried, very well might. The time to find out is before the platform is chosen, not after the screens are built.

Where low-code hits a ceiling

Two more limits are worth knowing in plain terms, because they tend to surface only once an app is busy and growing.

Scale. Low-code platforms are tuned for low to moderate volumes of data and users. They suit internal apps, dashboards, and business tools used by a team, rather than systems serving very high transaction volumes or huge numbers of simultaneous users 10. The limits are real and specific. In Power Apps, for instance, certain queries return only the first 500 records by default unless the app is built carefully to work around it, a constraint Microsoft documents openly so that builders design for it 5. None of this stops low-code being the right tool for a great many jobs. It does mean that “this will be processing millions of records, fast” is a signal to look harder at custom.

The platform sets the rules. With low-code, the business is building inside someone else’s product. That brings real benefits, including security and updates handled by the vendor, but it also means the platform’s limits become the project’s limits, and the ongoing cost follows the platform’s pricing rather than the business’s own choices.

Counting the real cost, not just the first invoice

Cost is where the two routes are most often compared unfairly, because the comparison usually stops at the build.

Custom software has the larger and more visible upfront cost: design and development from scratch is the bulk of it, and there is an ongoing cost afterwards to maintain and improve what was built. The business owns what it gets, and is responsible for keeping it running.

Low-code reverses the shape. The build is cheaper and faster, but the cost continues as a subscription for as long as the app is in use, and it tends to rise with the number of people using it. Microsoft’s Power Apps Premium plan, for example, is priced per user per month 6. For a small team that is excellent value. For an app that ends up being used by a hundred people for the next ten years, the running total is worth working out before committing, not after.

The useful habit here is to compare the two routes over the whole life of the app, not at the point of purchase. A rough rule: low-code usually wins on the first year and custom often wins on the long run for anything large or long-lived, but the crossover point depends entirely on how many people use it and for how long. It is an arithmetic question, and it pays to do the arithmetic.

A decision tree you can actually use

Putting the considerations in order gives a sequence an owner can walk through for any specific project. The strategic-versus-utility question comes first because it overrides much of what follows; the rest are tie-breakers for the genuine middle cases.

The figure is a guide, not a verdict. Real projects sit in the middle more often than the edges, and the honest answer is sometimes “a bit of both”.

The answer is sometimes both

One thing the either-or framing hides is that the two approaches are not always rivals. A common and sensible pattern, which Microsoft calls fusion development, is to build the bulk of an app on a low-code platform for speed, and write a small amount of custom code only for the few parts that need it 9. The business gets the quick assembly where the work is ordinary and the bespoke control where the work is genuinely demanding, without paying for a full custom build it did not need.

This is usually the right answer for a project that is mostly utility with one or two strategic corners. It is also the approach that asks the most of whoever is doing the building, because it needs judgement about which parts go which way. That judgement is the real value, and it is worth getting before the first screen is built rather than after.

A short checklist before you commit

A handful of questions, in roughly this order, will sort most projects:

• Is this part of what makes the business different, or just something it needs to run? Strategic leans custom; utility leans low-code 1.
• Does it have an awkward last 10 per cent? Unusual logic, a tricky integration, or a feature nobody else has tried is a warning that low-code may not reach the finish line 3.
• How big will it get? Very high volumes of data or users push towards custom 10.
• Who will use it, and for how long? Cost it over the whole life, not the first invoice, because low-code’s subscription keeps running.
• Could it be both? A low-code core with a little custom code is often the sensible middle 9.

There is no prize for forcing a project to the purist version of either answer. The prize is choosing the route that fits the job, so the thing that gets built is still the right thing two years from now.

Picking the right route for a particular project, and seeing where low-code, custom, and the blend of the two each earn their place, is most of the work. If a deeper look at how that decision plays out in practice would help, see how hirevolution approaches custom apps and portals.