Off-the-Shelf, Custom Build, or Low-Code?

When a business unit asks for a new application, three options usually come to the table: buy an off-the-shelf product, have it built from scratch, or develop it on a low-code platform. The discussion tends to run on cost. But because the three answer different questions, comparing them on price alone is misleading.

The real question is this: does this process differentiate you from your competitors, or is it work that everyone does in some form?

When is off-the-shelf the right choice?

If your process is an industry standard, a packaged product is usually the sensible option. In areas like accounting or payroll, the needs of thousands of organizations overlap substantially, and writing software to meet them means solving a solved problem again.

The real cost of a packaged product is not the license but the customization. If the product fits the way you work to a large degree, it is a good decision. Once you start bending the product to close the remaining gap, two things happen: every version upgrade turns into a project, and over time you become more dependent on your own customizations than on the vendor.

The question to ask at the decision point is whether you can adapt the process to the product. If yes, buy it. If no, closing the gap usually costs more than the initial estimate.

When is a custom build necessary?

Custom development is appropriate when the application itself is your competitive advantage, when technical requirements push past the limits of standard platforms, or when very specific performance, algorithmic or hardware integration needs are involved.

The visible cost of this option is development. The invisible one is ownership. The infrastructure, security patches, library updates, mobile compatibility and team handover of a bespoke application all belong to you. The question of who will carry that application in five years is on nobody's agenda in the first year.

Where does low-code sit?

Enterprise low-code platforms such as Mendix fill a third space: applications that are specific to your organization but not strategic.

That definition can sound abstract; examples make it concrete. Request and approval flows, field operations applications, dealer and supplier portals, inspection and audit applications, operational screens that pull data from several systems. These applications take their shape from the way you work, so they never quite fit a packaged product. But neither do they contain anything that justifies building a technology stack from the ground up.

What low-code contributes here is the technical layer that repeats in every project: user management, authorization, mobile compatibility, audit trail, deployment. The team focuses on business rules instead of rebuilding that layer.

Its second and less discussed contribution is speed, though not in the sense of typing code faster. Being able to show the business unit a working screen within two weeks surfaces a misunderstood requirement in days rather than months. A significant share of the time lost on enterprise projects goes not into coding but into requirements that were understood incorrectly.

The limits of low-code

To be honest about it, low-code does not suit every job. For software that needs heavy custom code outside platform standards, runs at very high transaction volumes, or will be productized and sold to a market, it is usually not the right tool.

Low-code also does not resolve an unclear scope. If process owners cannot agree on the approval steps, no platform will make that decision on the organization's behalf.

The lock-in question

"Will we be tied to this platform?" is a fair question, and it applies to all three options. With a packaged product you are tied to the vendor, with a custom build to the people who know that technology, with low-code to the platform.

What matters in the assessment is not whether a dependency exists but what it costs to leave. Can you get to your data? Is the business logic held in a readable form? Can you find a team to take the application over?

A short decision frame

• The process is an industry standard and can be adapted to the product: buy off the shelf
• The application is your competitive advantage, or technically out of the ordinary: build it
• You are talking about many organization-specific operational applications: low-code

Most organizations have room for all three. The mistake usually comes from applying one of them to every need.

If you would like to talk through which application belongs in which category, take a look at our Mendix work or get in touch.