In the past year, you may have had a moment where you started to believe you could build your own software.
You may have:
- Prompted Claude Code to build a personal web application and watched it stand up a functioning prototype in minutes.
- Spec’d a complex command line tool and spawned a full directory to perfectly meet your request.
- Set a team of agents on your codebase and uncovered technical debt you would have otherwise missed.
In any of these situations, hours of work from talented software engineers was condensed into minutes.
We are witnessing the barrier to building software systems come down. Software skills, previously reserved for a specialized group, are becoming accessible to a broader audience. In the coming years, we will likely see more people build fluency in software engineering and a net increase in new developers.
I have started to see this in my work supporting other founders as a technical advisor. Intelligent people from various industries (e.g. banking, international development, and medicine) want to build AI-enabled startups. They are venturing into tech-enabled territory both because of AI’s promise but because they can now quickly generate their own prototypes via prompting. These professionals that previously had limited-to-no exposure to building software are now neck deep asking questions about systems design.
I think this touches on a larger phenomena: more people will begin understanding how to build & sell good software. The first principles of software design will start disseminating to a larger audience and fluency will increase.
There is a growing belief that as the barriers to building comes down, everyone will start building their own software. That individuals can start cancelling subscriptions and organizations can start cancelling costly licenses to build bespoke solutions in-house. And that software of the future will be less about web applications with buttons & interfaces and more about agents communicating with one another through direct calls
I think this will be true in part. Many organizations may start building their own tools and many will continue to buy SaaS because the trade-off of building in-house will not be worth it.
The example I often use is spreadsheets. Today, anyone can open a spreadsheet and begin entering data. For some, generating a simple table with basic arithmetic is enough. For others, it’s useful for lookup & matching functions on larger datasets. And a few, it’s a central database with macros, scripts, and scheduled updates.
I believe the same will be true with software. We will see individuals start building their own homegrown tools. We will see organizations build bespoke software. And we will see agentic systems communicate with one another to 10x productivity. A broader audience of people will start building, but at different depths depending on their industry, technical expertise, and curiosity about system design.
At the organizational level, this shifts the job to be done from an external supplier to an internal team. Dollars that would normally get allocated to SaaS provider get shifted to internal corporate development. The company then needs to make some key decisions:
- How big of a team do we need to build internal products? Should it be one team or should we enable each division to become their own product org?
- What does this mean for launching new services? Are we hosting under a common set of providers or can anyone build based on their preferred stack?
- When do we ‘buy vs build’? Are there certain tools where we’re better suited with a SaaS provider? How do we consistently make that decision?
These are just some of the considerations. The point being is that the organization now owns the cognitive load of the SaaS provider. Everything from fixing bugs, customer success, and managing the product roadmap falls on internal teams. The real tradeoff becomes the benefit of having an internal team build internal tooling with AI vs the cost of allocating that to a SaaS provider.
Everyone may start building their own software, but that does not mean the first principles of building quality software systems goes away. They have to be learned by a broader number of people. The question then becomes how willing you are to understand and manage what you have built.