Thoughts on No-Code/Low-Code Hype

Disclaimer

This note reflects my personal experience with a specific no-code/low-code implementation in one project context. It is not a review of any particular product or platform, including Claris FileMaker, which I have not used in this case.

While I personally do not prefer FileMaker, the issues described here stem from how the no-code/low-code approach was applied in that environment, not from any one vendor’s technology.

Context

This is a bullet I saw coming but couldn’t dodge.

Last year, my boss sent me to assist a branch of some IT solutions provider firm, hoping to “test the waters” of no-code. On paper, I was there to evaluate the boundaries of their chosen platform — to see what it could and couldn’t do.

At first, I tried to stay detached — observe, assess, maybe write up a few notes. But slowly, expectations shifted. People started asking questions they thought I could fix. And then someone said the dreaded line: “You can code, right? Can you help with this?”

And like that, I was no longer evaluating.

I ended up figuring out their API integrations for them, poking at their so-called “database” and explaining why it’s nowhere near production-grade, let alone fit for banking systems like they imagined. I even built a few React/Next.js demos because, what a surprise, their no-code product couldn’t handle that.

At one point, I was halfway through building them a help center, 70% done, just to cover for what the platform couldn’t do. And then, mercifully, my boss pulled me out. Probably the smartest decision anyone made on that project.

What started as an “evaluation” quickly turned into damage control.

The Harsh Reality

If you’re Japan based, you must be awfully familiar with the no-code/low-code hype.

It’s everywhere, on huge billboards in train stations, sold as a silver bullet for “DX”, pitched in meetings by vendors who barely touch code, and pushed by managers who want results without ever touching the system's complexity.

In Japan’s enterprise scene, “fast delivery” often translates to bypassing engineers entirely. And that’s exactly what no-code promises: launch now, ask questions later. But the moment real-world requirements kick in: security, API integration, multi-language support, anything remotely modern… the platform begins falling apart. And guess who they call to patch it up?

By then, it’s too late to go back. You’re stuck maintaining something you never should’ve been handed in the first place.

It doesn’t make it faster.

You might get the illusion of speed and ease, dragging a few boxes, drawing some lines, and voilà, you just made a workflow! Except, what you just built will fall apart the moment it hits reality. You can’t refactor drag-and-drop. You can’t write tests for it. And when things go wrong, which they will, debugging is like spelunking in the dark, with no tools, no map, and no version history. It’s not fast. It’s rushed. And that’s a whole different story.

The API integrations are intolerable, to put it mildly.

Half-baked SDKs, broken OAuth flows, undocumented rate limits… choose your fighter. What’s pitched as “easy integration” often ends up being a tangled, nested mess of vendor-specific hacks. You find yourself writing more glue code to deal with the no-code platform than you would if you just talked to the API directly, except the no-code platform doesn’t let you. Or worse than that, they hide the failure modes so deep you only notice the data is missing when you’re knee-deep in the quicksand they market as a workflow.

It’s technical debt.

Worse even, it might be legacy debt. I had the horror to peek under the hood, it was coded like it predates modern practices and seemingly learned nothing from them. The stack I had to examine was built before React v17, and even v15 would have been an upgrade. The logic was procedural, the syntax unreadable, and the design choices unforgivable. The saddest part? This was the latest version available. Every “upgrade” was just a new layer of duct tape.

Technically speaking, you can exceed its limit by “customization”…

But here’s the catch, it means reinventing the wheel, the gearbox, and the combustion engine, all by your own hands. You’re not extending the system so much as building around its rotting core. And because it refuses to acknowledge modern tooling, with no npm, no module system, no support for TypeScript or even sane CSS in your arsenal, you end up writing one-off patches in a sandbox.

Lesson Learned

The lesson wasn’t just that no-code tools have limits, that much was clear. It’s how those limits shift the burden onto anyone technical who steps in later, how customers get lured into paying for an illusion they didn’t ask to be misled by.

What was pitched as “faster delivery” turned out to be technical debt disguised as progress. I spent more time deciphering undocumented workflows than I ever would have spent building something maintainable from scratch. And no matter how hard I tried, the results weren’t pretty.

These tools sell the illusion that users can build software “just like pros” without coding. But when things break, which they are doomed to, it’s not the citizen developers who get paged. It’s some poor devs like me, staring at a black box wrapped in spaghetti logic that doesn’t even support version control. It’s the customers, the end-users who get wounded by the very thing that was supposed to help them.

Closing Note

While I do not dismiss the potential of no-code/low-code tools in the right scenario, this experience reminded me the importance of matching the tool to the problem, and of planning for sustainability, not just speed. The value of code is not in the speed of deployment, but in clarity, traceability, and the ability to grow.

Besides, how can you call it a “fast delivery” when the thing you shipped barely holds under its own weight?