The Low-Code Gold Rush: Selling Shovels to People Who Don't Need to Dig

The low-code boom isn't really about building products. It's about selling the fantasy of building products to people who were never bottlenecked by code in the first place.

Photo by Hennie Stander on Unsplash

I’ve been trying to find case studies. Real ones. Companies that built something meaningful on a low-code platform, scaled it, maintained it, and are still running it profitably three years later.

The silence is deafening.

What I find instead are launch stories. “I built this in a weekend” threads. Revenue screenshots from month two. Then nothing. The accounts go quiet. The products disappear. The indie hacker moves on to the next thing.

This pattern tells you something important about what’s actually being sold here.

The shovel economics

There’s a reason the people who got rich during the California gold rush were mostly selling pickaxes and denim. The miners, by and large, went broke. The infrastructure providers made fortunes.

Low-code platforms are having their shovel moment. Bubble, Webflow, Glide, Softr, the entire ecosystem is growing at rates that would make a SaaS investor weep with joy. But the success stories from the people using these tools? They’re suspiciously thin on the ground.

I talked to someone at a low-code platform company last year. Off the record, obviously. They admitted that their best customers weren’t building products. They were building internal tools, prototypes, landing pages. Things that didn’t need to scale. Things that didn’t need to work perfectly every time.

“The platform grows when the dream grows. The dream doesn’t require the product to actually work at scale.”

That’s not a criticism of the platforms themselves. It’s an observation about what’s really driving the growth. And it’s not sustainable product companies being born.

Building was never the bottleneck

Here’s what keeps getting glossed over in the low-code narrative. Building a website has been effectively free since about 2004. WordPress, Squarespace, Wix. The tools existed. The templates existed. The hosting was practically free.

And yet most businesses still failed.

Because the bottleneck was never “can I build a website.” It was “do I have a business case that works.” It was customer acquisition. It was unit economics. It was figuring out whether anyone actually wanted the thing you were building.

Low-code doesn’t solve any of that. It just makes the building part faster. Which means you get to the part where you discover nobody wants your product slightly sooner. That’s not nothing, but it’s not what’s being advertised.

The marketing around these platforms sells capability as if it were outcome. “Build your SaaS in a weekend.” Sure. But the building was never the hard part.

The maintenance problem

I keep thinking about SLAs. About contracts with penalty clauses. About users on annual subscriptions who expect the thing to work.

Who fixes the vibe-coded creation when it breaks at 2am?

There’s a particular brittleness to low-code applications that becomes obvious the moment you need to debug something non-trivial. The abstraction that made building fast becomes the abstraction that makes fixing slow. You’re not looking at code you wrote. You’re looking at code the platform generated, filtered through a visual interface that may or may not expose what’s actually happening underneath.

I watched a founder spend three days trying to figure out why their app was timing out for users in certain regions. The answer was buried in how the platform handled database queries, something they had no direct control over and limited visibility into.

This is fine for prototypes. It’s fine for internal tools. It’s even fine for side projects with forgiving users.

It’s not fine when you’ve sold enterprise contracts with uptime guarantees.

“The speed you gain building is the speed you lose debugging.”

The fantasy of the one-person unicorn

There’s something almost predatory about how low-code success is marketed to solo founders. The message is relentless: you should be hitting a million in ARR within months. If you’re not, you’re doing it wrong. Your vibe-coded AI wrapper just needs better marketing. More Twitter threads. A different template.

The reality is that sustainable software businesses require sustained effort across multiple disciplines. Product development, yes, but also customer support, sales, operations, legal, accounting. The tools don’t solve for any of that. They just remove one (relatively small) obstacle from a path that has dozens.

I’m not saying solo founders can’t build real businesses. Some do. But the narrative that low-code enables this at scale is looking increasingly like survivorship bias dressed up as strategy. We see the rare wins. We don’t see the thousands of abandoned projects, the failed launches, the founders who burned out trying to support an application that was never designed to be supported.

The enterprise question

Here’s what I can’t stop wondering about. If these platforms are genuinely capable of building scalable, maintainable software, why aren’t enterprises buying them?

Not for internal tools. Enterprises do use low-code for that. I mean for actual product development. For the software they sell to customers. For the systems that run their business.

The answer, I think, is that the people with deep pockets and real requirements looked at low-code and saw exactly what it is: a tool for speed, not for scale. A way to validate ideas, not to build lasting infrastructure.

Corporations have IT departments and procurement processes and security reviews for a reason. They’ve learned, often painfully, that the thing that’s easy to build is often expensive to maintain. That technical debt compounds. That abstractions leak at the worst possible moments.

Where this probably ends

I don’t think low-code goes away. The platforms will survive. Some will thrive. The use cases that actually fit, internal tools, prototypes, simple workflows, those are real and valuable.

But the growth rates? The breathless projections? The “future of software development” rhetoric?

That cools off. It has to. Because eventually the market figures out that building was never the bottleneck, and the companies that succeed are the ones that solved the harder problems. The business model problems. The customer problems. The “why would anyone pay for this” problems.

The shovels keep selling for a while longer. The gold, as always, remains elusive.

I’m still looking for those case studies, though. Three-year-old low-code products with real revenue, real users, real operational maturity. If you’ve got one, I genuinely want to see it.

The silence continues to tell me something.