Low-Code Gives You More UI. That's the Problem.

Gartner projects that by 2026, low-code development tools will account for 75% of new application development. The market backing this projection is real: $44.5 billion by the end of 2026, up from far less just a few years ago.

The pitch: build faster, involve non-engineers, reduce the cost of software development. All of this is accurate.

What's not in the pitch: every low-code application is, by definition, an application that someone has to interact with. Low-code doesn't reduce the surface area of human-computer interaction — it lowers the cost of producing it. You now have a cheaper way to build more interfaces. More dashboards. More forms. More portals.

Whether you needed more interfaces is a different question that nobody asked.

The assumption embedded in "build"

Software development as an industry defaults to "build" as the activity. The goal is to produce a working application. Low-code accelerates this — more builds, faster, cheaper, by more people.

But for a significant category of problems, building is the wrong move entirely. The right move is to make the system behave correctly without requiring anyone to interact with it.

Consider: a developer leaves a team. Their open branches have context that's documented nowhere. The metadata is in their head and in their git history, but nobody synthesizes it. So someone builds an offboarding checklist app. Low-code, probably. Nice form. Required fields. Submit button.

Now there's a process that requires a human to remember to fill it out at the right time, fill it out correctly, and then someone else to read it and act on it.

The interface didn't fix the problem. It formalized it.

The actual fix is a system that tracks branch context continuously, surfaces it automatically, and doesn't depend on human action at the moment of departure. No UI required. The problem is solved structurally, not through a new surface area for human compliance.

"No UI" as a product philosophy

When I designed Ordia, the central decision was to build a coordination layer, not a coordination tool. The difference matters.

A tool asks to be used. You open it, interact with it, get a result, close it. A coordination layer operates continuously and surfaces its output into the tools you're already in — Jira, GitHub, Slack. You don't visit Ordia to check the state of your development pipeline. Ordia tells you what you need to know, in the context where you need to know it, without requiring you to go somewhere.

This is not a missing feature. It's a product philosophy. The software that works best is the software that doesn't ask to be noticed.

Low-code's entire value proposition is making it cheaper to build the kind of software that asks to be noticed. Faster, more accessible, more democratic access to the interface layer. But if the interface layer is the wrong layer to optimize, this is progress in the wrong direction.

What actually needs to be built

The low-code trend reveals something accurate about the demand: there are many problems organizations want to solve with software, and they can't always get engineering resources to build the solutions. Low-code addresses the resource constraint.

It doesn't address the design constraint. The question of what the software should do — specifically, whether it should ask humans to interact with it or whether it should just do the thing — requires thinking that tools don't automate.

Most enterprise software problems have an interface-heavy solution and a structure-heavy solution. The interface-heavy solution is visible and immediate: a new form, a new dashboard, a process embedded in a UI. The structure-heavy solution is less visible and more durable: a system that updates state automatically, routes information to where it's needed, and eliminates the manual step.

Low-code makes the interface-heavy solution much cheaper. This is why 75% of new applications will use it by 2026. The interface-heavy solution is now the path of least resistance.

That's the problem. Not the tools — the default.

The cost of more interfaces

Every interface in an organization is a compliance burden. Someone has to remember to use it. Someone has to fill it out correctly. Someone has to follow up when it isn't used. Someone has to maintain it when the process changes.

Software that runs without being noticed has no compliance burden. It has a correctness requirement — the underlying logic has to be right — but it doesn't depend on humans doing something at the right moment in the right way.

The proliferation of low-code apps is creating an invisible overhead: an expanding portfolio of tools that each require human action to function, each accumulating an audit trail of when the action didn't happen, each generating friction that didn't exist before the solution existed.

I have seen this on client projects. An internal tool is built to solve a coordination problem. For the first month, people use it. Gradually, the process around it drifts. The tool falls out of sync with reality. Now the tool is a source of misleading information in addition to the original problem.

The right question before building

Before reaching for a low-code tool: does this problem require a human to interact with software? Or does it require the system to behave differently?

If it requires human interaction, build the interface — fast, cheap, low-code, fine.

If it requires the system to behave differently, build the behavior. Don't build a form asking someone to confirm that the behavior should happen.

Low-code tools are not wrong. The default assumption that every problem is an interface problem is what's wrong. 75% of new apps using low-code by 2026 means 75% of new development is optimizing the interface layer. What percentage of those problems actually required a new interface is the number nobody is reporting.