For most of the software era, the relationship between builders and users has been oddly lopsided. The people writing code—often highly trained professionals working for companies with clear product roadmaps—rarely share the day-to-day reality of the people who depend on that code to do their jobs, run institutions, or manage their lives. Lawyers use case-management systems designed by teams that may never have sat through a deposition. Doctors rely on clinical tools shaped by regulatory constraints and engineering priorities that don’t always map cleanly onto the messy flow of real care. Teachers and church administrators wrestle with scheduling, communications, and recordkeeping software that was optimized for scale and maintenance rather than for the lived rhythms of classrooms and congregations.
The result is a familiar mismatch: software becomes a world you enter, not a tool you shape. The features are the features. The design is the design. If you want something else—something better, more aligned with your actual needs—you’re usually told to adapt, file a request, wait for a roadmap, or learn to code. That last option has long been treated as a joke, a punchline, or a last resort. But it’s also been the only reliable path to control.
Now, a shift is emerging that challenges this old bargain. The idea isn’t that professional developers disappear or that software becomes magically perfect. It’s that the distance between “making” and “using” may shrink—because more of the software layer is becoming personal, configurable, and increasingly shaped by the people who feel the pain of the current tools most directly.
This is where the story’s central provocation lands: the tyranny of software might be nearing its end—not because software stops being powerful, but because power is moving closer to the people who need it.
What’s changing isn’t just technology; it’s authorship
For decades, software has been built through a pipeline that naturally separates roles. Requirements come from product managers and customer research. Implementation comes from engineers. Deployment comes from operations. Feedback comes later, often after the system has already hardened into a workflow. Even when companies listen, they listen through the lens of what can be shipped, supported, and monetized.
But the modern software stack is increasingly modular. APIs, automation platforms, and AI-assisted development tools make it easier to assemble capabilities without starting from scratch. More importantly, these tools lower the barrier to experimentation. They allow non-traditional builders—people who aren’t professional programmers—to prototype, iterate, and deploy solutions that reflect their own context.
That doesn’t mean everyone becomes a developer overnight. It means the definition of “developer” starts to broaden. A person who configures an automation, designs a workflow, trains a model for a specific purpose, or builds a small app to solve a recurring problem is participating in software creation. They may still rely on templates and guardrails, but they’re no longer purely consuming someone else’s worldview.
In other words, the authorship of software is becoming more distributed.
And once authorship shifts, the priorities shift too
When the builder and user are the same—or at least tightly connected—the software tends to reflect different values. Not necessarily better values, but different ones. Developers optimize for correctness, maintainability, and generality. Users optimize for immediacy, clarity, and fit. Those goals overlap sometimes, but they diverge often.
Consider how many tools are designed around edge cases that matter to the company rather than the individual. A platform might support dozens of billing scenarios, but a small organization might only need one. A system might offer customization, but the customization might be locked behind permissions, complex settings, or a UI that assumes a certain level of technical literacy. A feature might exist, but it might be buried under steps that make it effectively unusable during the moments when it matters most.
When users become closer to the building process, the friction changes shape. Instead of asking, “Can we add this feature?” the question becomes, “What would make this workflow feel natural?” That’s a different kind of design thinking—less about adding options and more about removing obstacles.
This is why the story’s framing resonates: software doesn’t just deliver functionality; it defines the world users inhabit. If the world is defined by someone else, the mismatch is structural. If the world is defined by the people living in it, the mismatch can shrink.
Developer tools remain the strongest overlap—because they were built by people who also use them
There’s a reason developer tools often feel like the best-designed software in the market. The overlap between builder and user is unusually high. Engineers build tools they themselves will use daily. They feel the pain immediately. They notice when something is slow, confusing, or brittle. They also understand the tradeoffs required to make it robust.
That overlap creates a feedback loop that’s hard to replicate in other industries. In healthcare, for example, the people who experience the workflow are clinicians, but the people who build the software are often engineers and product teams operating under constraints like procurement cycles, compliance requirements, and vendor contracts. In education, the people who live the classroom are teachers, but the people building the platforms may be optimizing for district-level reporting and standardized deployment.
So the question becomes: can we bring the “developer tool” dynamic to non-developer domains?
The emerging answer is yes, at least partially—through personal software and user-driven creation.
Personal software isn’t just “apps”; it’s a new relationship with computation
When people hear “personal software,” they sometimes imagine a collection of apps on a phone—tools that look tailored but are still mostly prepackaged. That’s not the full story. Personal software, in the deeper sense, is software that is shaped around the user’s needs rather than the user being forced into the software’s assumptions.
This can happen in several ways:
First, software can become more composable. Instead of one monolithic product, users can assemble workflows from smaller components. A person might connect a calendar to a messaging system, route incoming requests to a tracker, generate drafts using AI, and then summarize outcomes automatically. The “app” becomes a living workflow rather than a fixed interface.
Second, software can become more conversational. Interfaces that allow users to describe what they want—rather than navigate menus—reduce the cognitive gap between intention and implementation. When the system understands the user’s goal, the user doesn’t need to learn the software’s internal logic as much.
Third, software can become more adaptive. With AI and automation, software can respond to context: the user’s preferences, the structure of their data, and the patterns of their work. That doesn’t eliminate the need for good design, but it changes what design means. It becomes less about predicting every possible scenario and more about guiding the system toward the right behavior quickly.
Fourth, software can become more ownership-oriented. The key isn’t only that the software is personalized; it’s that the user has a path to modify it. Ownership can be literal (the user controls the configuration) or practical (the user can iterate without waiting for a vendor).
These shifts collectively reduce the tyranny described in the story. The user isn’t trapped in a world created by someone else’s assumptions. They can reshape the world.
The “learn to code” escape hatch is getting replaced by something more realistic
For years, the advice to “learn to code” has functioned as both empowerment and gatekeeping. It’s empowering because it implies agency. It’s gatekeeping because it’s unrealistic for most people. Learning to code takes time, energy, and sustained motivation—resources that many users simply don’t have.
What’s different now is that the path to building is becoming more accessible. People can create useful software without mastering every layer of engineering. They can start with templates, use AI to draft code or generate logic, and rely on platforms that handle infrastructure concerns. The barrier is shifting from “write everything from scratch” to “direct the system toward your goal.”
This doesn’t mean the craft disappears. It means the craft is moving. The skill becomes specifying intent clearly, validating outputs, and designing workflows that match real-world constraints. That’s still hard—but it’s closer to the skills users already have: understanding processes, communicating requirements, and making judgment calls.
A unique take on the revolution: it’s not democratization alone—it’s localization
There’s a common narrative that this trend is about democratizing software creation. That’s true, but it misses a more interesting point: the biggest impact may be localization.
Software has historically been global in its assumptions. It’s built to serve broad markets, standardized workflows, and scalable deployments. Localization means tailoring software to local realities—specific organizations, specific communities, specific practices, specific constraints.
A lawyer’s workflow in one jurisdiction differs from another. A clinic’s documentation style differs from a hospital’s. A church’s administrative needs differ from a school’s. When software is built by distant teams, it tends to flatten these differences. When software is built by people closer to the ground, it can preserve nuance.
Localization also changes what “success” looks like. Instead of measuring success by adoption across a broad segment, success becomes whether the tool fits the daily rhythm of a particular group. That’s a different metric, and it can lead to more meaningful improvements even if the software remains small in scope.
In that sense, the revolution may be less about building massive new platforms and more about enabling countless small, highly relevant tools.
The risks are real: personalization can become fragmentation
It would be irresponsible to ignore the downsides. If everyone builds their own software, we could end up with fragmentation: incompatible workflows, duplicated effort, and inconsistent standards. Data silos could worsen if each personal app stores information differently. Security and privacy risks could increase if users deploy tools without understanding threat models.
There’s also the risk of overfitting. A personalized workflow might work perfectly for one person or team but fail when conditions change. And AI-assisted systems can produce confident errors—especially when users assume the tool is “just doing what I meant” rather than what it actually inferred