The promise of AI, coding agents is hard to ignore. Software development has undeniably accelerated, coding agents have changed the game. Today, software engineers spend far less time writing boilerplate code and far more time architecting systems, reviewing code, and making design decisions. Yet, despite these advances, Why haven't we seen a wave of domain experts - financial planners, urban planners, and researchers - independently building and publishing their own software solutions? Despite the power of AI, three invisible walls still stand in the way of the domain expert.
Why haven’t we seen a wave of domain experts - financial planners, urban planners, and researchers - independently building and publishing their own software solutions?
The Gap Between Knowing and Specifying
Domain experts possess a deep, intuitive grasp of their field’s problems often far deeper than any engineer. However, there is a massive difference between understanding a problem and specifying a technical solution.
Software doesn't just need to know what a good outcome looks like, it needs to know how data flows, how systems interact, and exactly what happens when things go wrong. Translating these understanding into a complete technical specification is hard. It’s not just about screens and buttons, it’s about how systems interact, how data flows, how edge cases are handled, and how decisions are encoded. Even with AI, incomplete or ambiguous specifications lead to software that “almost works,” but misses critical details that only surface later.
The Weight of Compounding Complexity
In the beginning, building an app feels like magic. But as soon as you add the second, third, or tenth feature, the “complexity tax” kicks in.
Every new button or data point introduces dependencies and unintended side effects. In software, complexity compounds. While an AI can generate a hundreds of lines of code in seconds, without good system knowledge it is hard to explain why a change in the User Profile broke the Payment Gateway. Understanding these ripples requires system-level thinking. Without it, a domain expert can quickly find themselves trapped in a “bug loop,” unable to reason through why their creation is suddenly falling apart.
The Hidden Half of Software: Infrastructure
Writing the code is actually only half the battle; the other half is keeping it alive.
To turn a script into a solution, you have to deploy it reliably, monitor it in production, manage failures, handle scaling, secure and compliant data, and control costs. While cloud providers promise simplicity, they often just trade one type of complexity for another. For a non-technical founder, the learning curve of infrastructure is a major barrier to entry. It’s hard to ship with confidence when you don’t fully understand the ground your software is standing on.
The Road Ahead
There’s no denying that software development is in the middle of massive change. In the last few years alone, we’ve seen more new tools, platforms, and approaches emerge than in the previous decade. Many of these are actively working to solve the exact problems above and make software more accessible than ever before.
If you’re a non-technical user who has tried to build software to solve a real problem, what challenges did you face along the way? Share your experiences and thoughts in the comments.