Software's Instagram Moment

Smartphones didn't create better photographers. They created more photographers.

Instagram won because it collapsed the gap between having an idea and sharing it with the world. Take a photo, apply a filter, post it. No darkroom, no portfolio website, no gallery submission. The barrier dropped to nearly zero and suddenly everyone was a photographer.

Photo: Rob O’Keefe

We're watching the same thing happen to software.

From gatekeepers to builders

For decades, writing software meant learning syntax, understanding data structures, wrestling with deployment pipelines. You needed credentials, training, usually a team. The barrier wasn't impossible, but it was high enough to keep most people on the consumer side.

Tools like Cursor, Claude Code, and Replit are changing that equation. You describe what you want, the AI writes the code, and minutes later it's running somewhere people can use it. Build it, ship it, done.

The result is more builders, not just technical people, but everyone! More people who can turn an idea into something that works. And when that happens, you get the same dynamic Instagram unleashed: people start building weird, personal, niche stuff that no product manager would ever approve.

Since I have been experimenting with Claude Code, I have made 3 websites, a CRM (personal contacts) app, a new knowledge repository, and an online email archive reader! Some of them with just one prompt!

The long tail of software

Think about what Instagram did to visual content. Before it, professional photographers and editors controlled distribution. Magazines, galleries, agencies decided what was worth seeing. After it, you got millions of images of coffee and sunsets and pets. Critics called it noise. But buried in that noise was a long tail of creativity that never would have existed otherwise.

Software is heading the same direction.

No business case. No VC pitch. No product roadmap. Just "I want this to exist" followed by a weekend of tinkering with an AI coding tool. A custom dashboard for tracking your kid's soccer stats. A tool that reorganizes your email by tone instead of date. A workflow automation that only makes sense for your specific job.

Most of it won't matter to anyone but the person who built it. That's actually the point.

The enterprise blind spot

This is where it gets interesting for large enterprises. Your engineering team is focused on strategic priorities, approved roadmaps, quarterly objectives. They're building the big stuff. Meanwhile, someone in a program office spent Saturday afternoon building a tool that automates a manual process everyone hated. They didn't ask permission. They didn't file a ticket. They just built it.

Shadow IT used to mean employees spinning up unapproved SaaS subscriptions. Shadow engineering is something different. Internal tools, workflow automations, data pipelines, even customer-facing experiments, built by people who don't have "engineer" in their title but now have access to tools that don't care about titles.

Is this a threat or an opportunity? I think it's both, and the balance depends entirely on how leadership responds.

The threat is real: security gaps, compliance issues, technical debt from code nobody knows exists. CISOs are already nervous, and within 18 months they'll be dealing with a visibility problem that makes unapproved SaaS look quaint.

But the opportunity might be bigger. The next wave of practical innovation won't come from your engineering team working through the approved backlog. It'll come from the person closest to the problem, who now has the power to solve it themselves. I've seen this pattern play out across my career. The best solutions often come from mission operators, not the technology team. What's changed is that those operators can now act on their ideas directly.

So what do you do with this?

Instagram didn't make professional photographers obsolete. It expanded who got to participate and what counted as photography. The best professionals adapted. They used the platform. They learned from the creativity happening at scale around them.

The same will happen with software. Professional engineers aren't going away. But the boundary between "builder" and "user" is dissolving. Organizations that treat this purely as a governance problem will miss the bigger shift.

The question isn't "How do we stop this?" You can't, and you shouldn't want to. The question is whether you create conditions where this energy becomes a source of advantage, or whether you drive it underground where it creates real risk.

That means rethinking permissions, tooling, and governance. But mostly it means rethinking culture. Do you punish the person who builds something without asking? Or do you figure out how to channel that instinct into something the organization learns from?

We're early in this shift, and the organizations that figure out the right balance of openness and governance will have a real edge. The ones that default to lockdown will lose their most creative people to places that let them build.

I'm curious what you're seeing in your organizations. Are people already building things on their own? How is leadership responding? Reply in the comments on what you think!

The ideas in this blog are mine, I used AI (Claude Opus) to proofread and tweak the writing.

This first appeared on LinkedIn: https://www.linkedin.com/pulse/softwares-instagram-moment-rob-o-keefe-uvsoe