Why Smaller Software Is Suddenly Worth Building

I’ve built more software this year than in the previous five combined, mainly because the cost of turning an idea into something real has collapsed.

Around a year ago I set myself the challenge of building VisaScope AI as a no-code product. I was late to the no-code movement but wanted to prove I could build something useful without writing code, and I covered the build in a three-part series that ended with me hitting the limits of Landbot. Somewhere along the way though I lost sight of why I was building it and became obsessed with making the technology work rather than delivering the product. I’ll come back to that in a follow-up to the series, but the short version is I paused it and started experimenting with Claude Code, Lovable and AI-assisted development instead, and I haven’t really stopped since.

What I built this year

This year alone I’ve built four products of my own. Weather Alert Spain emails official Spanish weather alerts in English and Pass PM Exams is a practice site for product management exams. AI Splicer turns long AI conversations into structured summaries and Continuum is a personal organiser with a Kanban board, wired into my Google Calendar with MCP. Alongside those I’ve built a browser remake of a 90s game so my brother and I can play together and a Fighting Fantasy tracker, and rebuilt three websites, Product Scope, Henao Legal and My Portable Life, which finally let me retire WordPress for good, sorry old friend.

The same approach has carried into my client work. For BAFTA I prototyped an AI support agent for BAFTA View that is now live, after a BAFTA developer hardened it for production and merged my own fixes into the production code, and I redesigned the BAFTA Events admin interface with Claude Code. At BMT I built a support dashboard that pulls time data from Jira, which I come back to below.

None of these are particularly large projects, but every one solved a real problem, either mine or a client’s. The reason I’ve been able to build so much is that turning an idea into a working product now costs a fraction of what it used to, both in money and in the amount of development effort required.

Building Notion for one

For years I’d accepted that if software didn’t quite fit my workflow then I’d adapt my workflow instead, because that’s just how SaaS worked. You picked the closest product, compromised a little and carried on. Notion was probably the point that changed for me. I genuinely liked it, bought a year’s licence and moved my documents and processes across, but the more I used it the more I found myself compromising: my Make automations didn’t quite work the way I wanted, and small things behaved differently to how I’d have built them myself.

Normally that’s where the story stops, but this time I sat down with ChatGPT and Claude, talked through what I wanted and started building my own version, which became Continuum. I didn’t write a full specification up front and built it step by step instead, reworking it as I found out what I actually wanted, because I was building software for one person rather than a Notion competitor.

Building for one user means that if I don’t like a feature I junk it, and if I want something new I just build it, without waiting for a roadmap or convincing thousands of other customers that my request is worth prioritising. At some point I might share it or even try to sell it, but that is not really why I built it.

Why one user is enough

The best example is probably Weather Alert Spain. It currently has seven registered users, and I’ve never advertised it, posted it in a forum or really tried to grow it. Every Monday it emails me the previous week’s usage. Some weeks nobody has used it, other weeks one extra person signs up and I tell my wife straight away.

A year ago I’d probably have looked at seven users and called the project a failure. Now I think seven might be enough, and that’s probably the biggest shift in how I think about software this year. I made the product because I needed it, it solves the problem for me and a handful of other people now get some value from it as well.

There will obviously be people who are much more entrepreneurial than I am who take the same tools and build products for much larger audiences. But there is now far less pressure for every piece of software to reach a huge audience simply to justify the cost of creating it. A product can be very specific, serve ten or twenty people and still have been worth building.

Small internal tools

The same applies inside organisations. The support dashboard I recently built for BMT pulls time from Jira and JSM so the team can see where support and development hours are going, a job I had previously done by hand and which neither Atlassian’s own reporting nor a plugin had solved. It took around four hours to build and serves a small team, but it replaces most of a manual process that took several hours each time and was normally months behind.

Where the cost hasn’t fallen

Enterprise software is still a very different proposition. Running something like BAFTA’s Nucleus platform is a completely different challenge. It supports more than fifteen clients, and the cost of creating and running that kind of software has fallen a lot less than the cost of a weekend project.

Security updates, GDPR compliance, support, API changes, monitoring, backups and reliability still matter exactly as much as they always did. The BAFTA View support agent showed me the gap clearly. I could prototype it quickly, but before it went live a BAFTA developer had to connect it to the real member login, encrypt each member’s conversation history and fix sixteen issues found in a security review. A personal product can tolerate things that a business-critical platform simply cannot, and once other organisations depend on a product the ongoing cost and responsibility become much more significant.

Even small tools carry some of that cost. Weather Alert Spain only has seven users but still needed proper work on sign-in and permissions, and the BMT dashboard needed a security review before anyone relied on it because it holds client billing data. The line is less about the size of the product than how much is at stake if it goes wrong and how many people depend on it.

What I think happens next

I don’t think SaaS is dead. Large organisations will continue to need reliable, supported platforms with teams behind them for the systems they depend on, but underneath that I think we are going to see an enormous increase in smaller personal and internal products because it is now economically viable for far more people to build software that might only ever serve a handful of users.

Some of those products will disappear within a few months because they have stopped solving a problem. Others will gradually turn into something larger, while plenty will probably spend their entire lives with ten, fifty or a hundred users. I think that’s fine, because they no longer necessarily need thousands of customers to justify being built in the first place.

I think the future contains a lot more software, much of it smaller and much more specific to the people using it. AI has dramatically lowered the cost of turning an idea into something real, and for someone who has spent years designing products without necessarily being able to build them personally, that has opened up an entirely different way of thinking about what is worth creating.

I’m already working on both sides of this, building small internal tools like the BMT dashboard while continuing to manage established platforms like Nucleus. The interesting part for me now is working out where a fast AI-assisted build is enough and where the scale, risk or importance of the product demands something more substantial from the start. Looking back at how much I’ve built over the last twelve months, I don’t think I’m anywhere near finished yet.