The Democratization Mirage: Why "Everyone Will Just Build Their Own Apps" Misses the Point

22 May 2026

I grew up in Palm Springs. I’m actually fourth-generation Palm Springs, which means I grew up with mirages, not as a figure of speech, but as a daily fact of desert life. On a hot afternoon, the road ahead shimmers with what looks exactly like water. It's convincing. It's physics. And everyone who lives there long enough learns the same lesson: the fact that you can see it doesn't mean you can reach it. The mirage is real. The water isn't.

The Mirage Appears Again

I've been thinking about mirages and Palm Springs a lot lately, because the technology industry has a version of this phenomenon that recurs with remarkable regularity, and we're in the middle of another one right now.

Every decade or so, a new technology arrives carrying the same promise: this time, the gatekeepers fall. This time, the specialized knowledge that used to require years of training, or expensive professionals, becomes available to everyone. This time, ordinary people will just do it themselves.

Right now, that promise is attached to AI-powered coding tools. The argument goes: building software has gotten so easy that companies no longer need to buy workplace apps. Teams can just build exactly what they need. Why pay for someone else's product when you can make your own? I call this the democratization mirage. Instead of water, the mirage is the hope that something exists that will make things better, more accessible.

It's an appealing idea. It's also a mirage–not a lie, but something that looks closer than it is, and shifts as you approach it. I recognize this because I've seen it my whole life and career.

The Technology Mirage Has Appeared Before

The HTML prophecy (1990s)

When the web arrived, the argument was that publishing would be democratized. HTML wasn't hard. Anyone could build a site. Why would you need a web designer?

A small percentage of curious people did learn HTML. Most dabbled and quit. The vast majority never opened a text editor. What actually emerged wasn't a world of self-built sites, it was a generation of abstraction tools: GeoCities (my alma mater!), Blogger, WordPress, Squarespace, and so on, because most people don't want to build, they want the outcome. Meanwhile web developers didn't disappear; demand for them grew as the total surface area of the web expanded far beyond what the early adopters could cover.

The spreadsheet paradox (1980s–90s)

When VisiCalc launched in 1979, and later when Lotus 1-2-3 and Excel became ubiquitous, the prevailing prediction was that accountants were finished. Why hire a professional to crunch numbers when a machine could do it instantly?

The opposite happened. As personal computers and spreadsheets proliferated through the 1980s and 1990s, accounting and auditing employment in the U.S. grew significantly. This counterintuitive dynamic has occurred across multiple professions: ATMs were supposed to eliminate bank tellers, yet teller employment rose for decades after their introduction because branches became cheaper to operate and banks opened more of them.

The mechanism is the same each time: a tool lowers the cost of a unit of work, which expands demand for that work, which more than offsets the productivity gains. Spreadsheets didn't replace accountants, they made financial analysis affordable enough that every department wanted more of it, which created more need for people who could do it well.

Desktop publishing, photography, no-code (and on)

The pattern repeated. Desktop publishing tools in the 1980s meant "anyone can design," but instead of eliminating designers, the demand for designed materials exploded as small businesses could suddenly afford them. Digital cameras and smartphones put professional-grade photography in every pocket, the market bifurcated, with casual photography booming and demand for skilled photographers growing as clients became more visually literate. No-code and low-code platforms promised to replace developers, and created an entire profession of no-code specialists while revealing that product thinking and systems design are hard regardless of whether you're writing syntax.

Each time, the mirage appeared. Each time, it moved.

Why the Mirage Keeps Appearing

The democratization mirage isn't random. It recurs because it's structurally appealing to almost everyone involved.

Tool makers benefit from the narrative. "Anyone can use this" is a powerful marketing claim. Buyers feel empowered by it. Pundits and forecasters get a clean, optimistic story about technology leveling playing fields. Heck, I’ve used these same taglines in products I have created! But the people who quietly absorb the reality, the developers still hired, the specialists still consulted, the professionals who just moved up the abstraction ladder, rarely make headlines.

There's also something genuinely true in it, which is what gives the mirage its staying power. Barriers do fall. Some people really do learn to build their own tools. Access really does broaden. But democratization of access is consistently mistaken for democratization of outcomes, and that's where decisions go wrong.

The bottleneck doesn't disappear. It relocates.

What the Mirage Hides: Where Complexity Goes

When a tool removes one layer of difficulty, it reveals the layer beneath. This is what the "just build it" narrative reliably underestimates:

Maintenance. Every app, however simple, degrades over time. Dependencies break. Edge cases surface. Data gets messy. Someone has to own it, indefinitely. The weekend build becomes the Monday morning problem six months later.

Requirements. Knowing what to build is a distinct and demanding skill, entirely separate from the ability to build it. It requires understanding how people actually work, where friction lives, what will cause adoption to fail. This doesn't get easier when the tools get simpler.

Integration. Workplace software doesn't exist in isolation. It touches authentication systems, existing data, and other tools in the stack. Connecting things correctly is where most of the complexity hides and where most amateur builds eventually break.

Security and compliance. For workplace tools especially, tools that handle people data, communications, organizational knowledge, questions of access, ownership, and accountability aren't optional features. They're load-bearing. They require sustained attention, not a one-time setup.

These same complexities apply to learning how to play the guitar or the piano. Yes, some people learn guitar and piano. Most who try quit within months (this would be me with my guitar studies!), and even dedicated learners generally don't write original compositions, book the venue, manage the sound system, and handle ticketing. They play guitar. Specialization persists because it's genuinely hard, independent of whether the instrument is accessible.

The Abstraction Ladder is What Actually Happens

The real pattern across all these moments isn't that tools make specialists obsolete. It's that tools shift the level at which specialists operate.

When Excel arrived, accountants stopped computing sums by hand and started doing financial modeling. When Webflow arrived, developers stopped writing CSS from scratch and started building design systems. When AI coding tools arrive, developers will stop writing boilerplate and start solving harder problems. The abstraction layer rises; the specialist rises with it.

Each step up the ladder also expands the total market. More people can now participate at the lower levels, which is real and valuable, but it simultaneously reveals new complexity at the higher levels that tools alone can't traverse. The ceiling doesn't disappear; it just gets more interesting.

What This Means for Workplace Software

For companies choosing how to equip their teams, the mirage has a practical cost. The promise of "your team can build whatever they need" contains a hidden variable: someone's sustained time, attention, and judgment. Those are finite resources, and they have opportunity costs.

Most teams are genuinely better served by software built by people who have thought deeply about the problem space, who have made the hard tradeoffs in product design, who maintain the infrastructure, who absorb the security and compliance burden, than by a bespoke internal tool that someone built in an afternoon and now quietly owns forever.

The question isn't whether AI tools are powerful. They are. The question is what happens when the initial excitement fades and the real work of running reliable, secure, integrated software begins. That work doesn't vanish because the build got easier.

Back to the Desert

The democratization mirage is powered by genuine hope: the hope that this time, complexity has finally been tamed, that expertise is no longer a bottleneck, that everyone gets the same access to the same outcomes. That hope is worth honoring. Technology does change things. Access does matter.

But mistaking a lower floor for a removed ceiling is an expensive error. The future of work isn't everyone becoming a developer. It's everyone gaining more powerful leverage, and the people who understand how to use that leverage well become more valuable, not less.

I learned early, growing up in the Palm Springs desert, that a mirage isn't a trick or an illusion cooked up to fool you. It's science. It's light behaving exactly as light does under extreme conditions. The mirage is real. The water isn't. And the people who make good decisions in the desert aren't the ones who deny the shimmer, they're the ones who've learned not to walk toward it thirsty, convinced they're almost there.

The smart move, in the desert and in technology, is to see the mirage clearly before you start walking.