Building Is Now Easy. Owning Is Not.

I’ve been building. Despite telling you that people will not. Over the last four months I have built eight different pieces of software.

I thought you would be interested in my conclusions - that AI has made building trivial, that SaaS is dying, that anyone can now ship a product in an afternoon - is not what I found. What I found was more interesting and, I think, more useful if you are trying to work out what this means for your business.

The builds

My first one started with necessity. I had built an MCP server at my previous company - a tool that connected our AI workflows directly to LinkedIn Ads - and I missed its productivity benefits. So I rebuilt it adding Google Ads while I was at it. That one is now live.

The second was to help my daughter, sitting her GCSEs (and also to how far I could stretch AI and myself). I wanted her to get faster at mental maths, so I built an Android game. I started in 2D (much easier!), but decided that was uninspiring, and added a 3D racing track with maths checkpoints at each gate. That is in the app store now. GCSE SpeedSolve: Maths.

The third was the misstep. I missed Google Reader. It was an RSS that pulled in content from around the web. It disappeared years ago, and I thought I could rebuild it whether a site had RSS support or not. It worked. And then I realised I did not need it. I could just get my AI agents to monitor the sources I cared about and surface summaries on a schedule. The problem I had been trying to solve now needed to be solved differently because the way I consumed content was different. That one is sitting in a drawer while I decide what to do with it.

The 4th was due to laziness and my love of data. I built a social media MCP server for posting and analysis. That is live and eventually should speed up what works better in social media for me specifically.

5th was me looking to expand the gaming app series by adding a GCSE German vocabulary app. This is unfinished. More on that in a bit.

6th, I built a podcast player. I didn’t anticipate this one as I thought there were enough podcast players around. But because I follow people rather than shows, and I wanted an agent to monitor specific people and automatically add their appearances to a playlist I can play in my car, I ended up building one along with an associated MCP server to enable it to work with my AI agents.

Finally 7th, I started working on a 2D fighting game — think old Street Fighter — to add as a mode to the maths game. This was again really about me seeing how far I could stretch AI and my capabilities. It is unfinished right now.

While building the German vocab game, I looked at the list of apps I was working on and realised almost nothing was finished. I had been building constantly and shipping almost nothing. So I stopped. I focused on the MCP server and the maths game. Got both live. Then returned to the rest.

The part nobody mentions - what I learnt

Here is what the “AI makes building easy” commentary skips.

You own it now.

The MCP servers connect to third-party APIs. LinkedIn updates their API. Google Ads changes parameters and deprecates endpoints. Every platform update is a maintenance event that requires me to check the impact on the new updates. AI could be automated to do the monitoring and even the changes. It can even test to ensure everything still works but it is not good enough to understand the knockoff effects and edge cases.

The mobile apps are the same story — Android platform updates, security patches, app store requirement changes. These are not dramatic events. But they are continuous, and they are your responsibility.

For B2B platforms, the bigger challenge is staying on top of what is possible. What is the next best practice and now needs building. It is time thinking and monitoring that could be spent on your core business instead.

There is no way I am going to build dozens of apps. But it is easy to build apps, test them and see what you want to keep and grow.

What has actually changed

Building software is faster. Significantly faster. The gap between having an idea and having something working has compressed in a way I would not have believed two years ago. That is both new and significant.

But the things that matter after you build - the discipline of deciding what to actually finish, the judgment to recognise when you have solved the wrong problem, and the commitment to maintain and improve what you have shipped - those have not changed at all.

The RSS reader is a good example of this. I built it. It worked. And it turned out I had been solving for the wrong thing, because the thing I actually needed was not a reading interface but a content curation layer, which AI handles better than any RSS reader could. Faster building means faster arrival at that kind of insight. But you still have to do the thinking.

The question for your business

“What could we build?” is a reasonable starting point. But it is not the right question on its own.

The better questions are: what should we build versus buy, given we now understand the true cost of each? Are we prepared to own and maintain what we build? And are we solving the right problem, or just the most obvious one?

AI has changed the things here significantly. The barrier to building has dropped and the value of custom tools, built precisely for your workflow rather than adapted from something general, has gone up. But maintenance is still a cost. Shipping discipline is still required (even if it is just for your own internal use, code needs to be hardened and secured). And the judgment about what to build in the first place matters more than ever, not less, precisely because the option to build is now always on the table.

SaaS is not going anywhere. But the decision about when to build versus buy has shifted.

One thing worth reading

We Taught AI to Write Code But We Forgot to Teach It to Think — The AI Corner

Developers report feeling around 20% faster with AI coding tools. Measured end to end, teams are frequently running 19% slower - because understanding and debugging code you didn’t fully author is harder than writing it was. The comprehension debt building inside AI-generated codebases is the less visible version of the maintenance problem described above.

One thing to try

Write down one process in your business where the tool you use requires the most manual workarounds or simply does not quite fit. Then ask two questions before deciding what to do about it: what would a purpose-built solution actually need to do, and who would be responsible for keeping it current in 18 months?

If you can answer both clearly, it might be worth building. If the second answer is vague, that is your real problem - not the tool.