Low-code and no-code vs Custom development

The labels are marketing categories as much as technical ones, so it helps to describe what each kind of tool lets you do. No-code tools are built for people who do not write software. Everything happens through visual configuration: tables, forms, drag-and-drop screens and if-this-then-that automation. Spreadsheet-database hybrids such as Airtable, integration tools such as Zapier and Make, and visual web app builders such as Bubble are well-known examples. The ceiling is the platform’s feature set. If the platform cannot do something, neither can you.

Low-code platforms aim at a mixed audience that often includes professional developers. They offer the same visual building, plus a way to write code where the visual tools stop: custom functions, scripts, components or calls to external services. Enterprise platforms such as OutSystems and Mendix sit here, as do developer-focused internal tool builders such as Retool. Microsoft Power Apps spans both ends, with a formula language, Power Fx, that business users can learn and extension points for developers. Large business platforms also embed low-code tools for building on their own data, Salesforce and ServiceNow being familiar examples.

The distinction matters for two reasons. The ceiling is higher on low-code, because you can drop into code when you need to. The lock-in is usually similar, because that code runs inside the platform, against its runtime and data model, and does not come with you if you leave. A newer category complicates the picture: AI app builders that generate a whole application from a written description. These produce real code, often exportable, which changes the lock-in calculation, but they share the central no-code risk that the person who built the application may not understand how it works.

Custom development is the reference point for all of these. Engineers write the application in a general-purpose language and framework, keep it in version control, test it with standard tools and deploy it to infrastructure they choose. It is slower to start, and its only ceiling is the team’s skill and the budget.

The speed of low-code platforms is real, and it comes from what they hand you before you start. Sign-in, hosting, a database, form controls, an approval engine and a publish button already exist. On a typical internal app that scaffolding is a large share of the work, and the platform makes it disappear. A first version of a request-and-approve tool can be in users’ hands within days.

That advantage is front-loaded. Each additional feature on a platform tends to cost a little more than the last, because it has to fit around the platform’s model and around the workarounds already in place. In code the early effort is higher, but a well-structured codebase keeps each new feature roughly as costly as the one before. Simple apps never reach the point where those two curves cross, which is why low-code wins for them. Applications that keep growing usually do reach it.

The gap at the start has narrowed, too. Mature web frameworks, managed authentication services, hosted databases, component libraries and AI coding assistants mean an experienced team can stand up the scaffolding of a conventional application much faster than was typical a few years ago. Platforms are still quicker for the simplest apps. For anything moderately complex, the difference in time to a first version is smaller than vendor demonstrations suggest, and the difference in time to the tenth version can favour code.

The honest way to measure speed is across the life of the application. Ask how long the first version will take, and then how long the twentieth change will take, after the original builder has moved on and the requirements have grown. That second number is the one most comparisons leave out, and it is usually the one that decides whether the choice was right.

The most attractive promise of these platforms is that the people who understand a process can build its software themselves. Staff who build applications without being professional developers are often called citizen developers, and when it works it removes the slowest part of software delivery, which is explaining the problem to somebody else. An operations manager who can fix a form or add a step to an approval flow in an afternoon is a genuine asset.

The weakness is continuity. Citizen developers have other jobs, change roles and leave. Their applications stay behind, often undocumented, sometimes running under a personal account, and occasionally critical to a process nobody realised depended on them. Platforms maintain their own runtime and security, but nobody maintains your app unless you assign someone to. Platform changes, such as a retired connector or altered behaviour, can quietly break an app whose builder is no longer around to notice.

Professional developers working on low-code platforms meet a different problem. The skills are platform-specific, the tooling is less flexible than they are used to, and practices they rely on, such as reviewing changes line by line and running automated tests, may be awkward or missing. Some enterprise platforms handle this well. Many lighter tools do not, and good engineers tend not to stay long in roles built entirely around them.

Whichever route you take, the rule that prevents most failures is the same: every application in use has a named owner, a documented purpose, and a successor if that owner moves on. For custom software the ownership question is who maintains the code, and it is usually asked. For platform apps it is who maintains the app, and it is asked far less often than it should be.

Platform ceilings are rarely a hard wall. They behave more like a slope, where each step beyond the platform’s comfortable territory costs more than the last and the workarounds accumulate. It is worth knowing where the slope starts in the three areas that cause most rebuilds.

Logic first. Visual flows and spreadsheet-style formulas handle forms, routing, notifications and simple calculations well. As branching multiplies, they become harder to read than code expressing the same thing, and much harder to review: you cannot easily see what changed between two versions of a diagram, or write a unit test for one branch of a flow. Complex pricing, allocation, scheduling and permission rules are where this bites, and the result is a form of technical debt that is harder to pay down than its equivalent in code.

Performance next. The runtime belongs to the platform, so you cannot tune it. Platforms set limits on how much data an operation processes, how long an automation may run and how often it may call other systems, and some only work efficiently when a query can be handed down to the underlying data source. These limits rarely show in a pilot with a few hundred records and a handful of users. They show at production volumes, when an app that felt quick becomes slow and the only fixes available are workarounds rather than optimisations.

Integrations last. Mainstream platforms ship long lists of connectors, and if every system you need has a good one, integration is a platform strength. The difficulty is the system without one: a legacy application, an unusual partner API, a file drop, a piece of hardware. Some platforms let you build custom connectors, which helps. Others leave you stuck, or push you towards a separate service written in code anyway, at which point you are maintaining custom software and a platform app side by side.

Platform pricing comes in a few structural shapes, often combined: per user per month, per app, per automation run or task, by consumption of compute or storage, with higher tiers for premium connectors or features, and separate arrangements for external users such as customers or partners. Exact prices and plan boundaries change often, so check the current rate card. The structure is what matters for planning, because it decides how the cost grows.

For a small team on a few internal apps the cost is usually modest, and well below what building and hosting equivalent software would cost. It grows with the things that grow when an app succeeds: more users, more runs, more data, more connectors. An app that began as a departmental tool and spread across the organisation, or one opened up to customers, can move from the cheapest option to the most expensive without any single decision causing it. Model the cost at the scale you hope to reach, and agree in advance what level would prompt a rethink.

The lock-in is structural. On most platforms the application exists only as configuration inside the product. The data can usually be exported; the screens, logic and automations generally cannot be turned into code you could run elsewhere. Leaving means rebuilding the application, and that rebuild is the real exit cost. Some AI app builders and a few low-code platforms do generate exportable code, which is worth checking if portability matters to you.

Three habits keep the exit affordable. Keep important data in a system you control, such as a proper database or an established system of record, rather than in the platform’s own tables, so a rebuild only has to replace the application layer. Write the business rules down outside the platform, in plain language, as you build. And review the cost and the dependency once a year, while switching is still a choice rather than an emergency.

Shadow IT is software adopted or built without the knowledge of the people responsible for security and data. Low-code and no-code tools did not invent it, since spreadsheets and personal cloud accounts were doing the same long before, but they make it far easier to build something substantial without anyone in IT knowing. That is both the opportunity and the risk.

The risks are specific. Customer or employee data copied into an app nobody has reviewed. Automations running under one person’s credentials, which stop working when that person leaves or changes their password. Connectors sending data to services the organisation has never assessed. Business-critical processes running on an app with no owner, no backup and no record of how it works. None of these is unique to low-code, and all of them become more common as building becomes easier.

Banning the tools rarely works. Demand for small applications does not disappear; it moves to spreadsheets, personal accounts and tools nobody can see at all. The more effective approach is to provide a governed platform and make it the easy option: separate environments for experimenting and for production, data policies controlling which connectors may be used together, an inventory of apps and their owners, and service accounts rather than personal ones for anything important.

Governance should also define a route upwards. When an app becomes important to many people, handles sensitive data or starts hitting the platform’s limits, there should be a known path for it to be reviewed, properly supported or rebuilt by engineers. A good deal of business automation work begins at exactly that point: a process that has proved its value on a platform and now needs to run reliably at a larger scale.

AI coding assistants have become a normal part of many engineering teams’ work. Tools such as GitHub Copilot, Cursor and Claude Code suggest code, write tests, explain unfamiliar codebases and carry out multi-step changes under an engineer’s direction. This affects the comparison on this page, and it is worth being careful about exactly how.

What has changed is the cost of writing routine code. The scaffolding of a conventional application, data-entry screens, integrations against documented APIs, test cases and repetitive changes can be produced faster by an experienced engineer working with these tools. That narrows the speed advantage platforms held for simple and moderately complex applications, and it lowers the point at which custom code becomes the economical choice.

What has not changed is the cost of everything around the code. Someone still has to understand the problem, design the data model, decide how the system behaves when things go wrong, review what was generated, secure it, host it, monitor it and maintain it for years. Generated code that nobody understands is a liability in the same way as a platform app nobody understands. The tools make good engineering practice faster. They do not replace it, and they make poor practice faster too.

The platforms are adding AI assistance of their own, and AI app builders that turn a description into a working application now sit between the two categories. For prototypes and throwaway tools those builders can be remarkably quick. For software that has to be maintained, the usual questions apply: who understands it, who owns it, and what happens when it needs to change. The boundary has moved rather than vanished. Custom development is now a reasonable option for smaller problems than it used to be, provided the team using these tools has the engineering discipline to own what they produce.

The most common sensible path is sequential. Build the first version on a platform, put it in front of real users, learn what they actually do, and rebuild in code the parts that outgrow the platform once their shape is clear. A platform prototype is often a better specification than any document, because people have used it. Treated as an MVP, it answers whether the idea deserves engineering investment before that investment is made.

The path works when it is planned from the start. Keep the data model clean and, where you can, keep the data somewhere other than the platform’s own tables. Write the business rules down as they are decided. Agree in advance which signals will trigger a rebuild: user numbers that push the licence cost past an agreed level, an external audience, performance complaints that cannot be fixed, a regulatory need for proper testing and audit, or the discovery that one person is the only one who understands the app.

When the rebuild comes, rebuild the part that hurts rather than everything. Move the data to a proper database first if it is not already in one; many platforms can read from an external database, so the existing app keeps running against it in the meantime. Then rebuild the heaviest workflow in code, run it alongside the platform version, move users across and retire the old flow. Parts of the platform app that still fit can stay where they are. The screens and the documented rules carry over as a specification. The platform logic does not, and it should be read for rules rather than translated step by step.

The move occasionally runs the other way, and that is legitimate too. A custom internal tool nobody maintains, built for a process that has since become standard, may be better replaced by a platform app or an off-the-shelf product. The test is the same in both directions: put each application where the people who will own it can maintain it safely, at a cost that matches what it is worth to the business.