Last month I watched someone on X announce, with entirely justified pride, that they had built and launched an app over a single weekend using AI. Landing page, subscription billing, App Store listing, the lot. By Monday morning there were paying customers and hundreds of congratulations.
Mine would have been among them. It genuinely was impressive. I’ve been building commercial software for a bit over thirty years, and these days Claude and ChatGPT are open on my desk every working day. AI has fundamentally changed how I work, and I’m dramatically more productive for it. I want that on the record before anything else, because this is not that kind of article.
But I noticed something about my own reaction. I never once wondered how they’d built the app. I found myself wondering who would still be supporting it in three years.
That reaction told me what this article is actually about, and it isn’t AI. It’s trust. The interesting question is no longer how quickly software can be built. It’s how long it can be trusted. And that question was precisely the one nobody in the replies was asking.
The tools deserve the hype
Let’s be clear about the tools first, because they’ve earned it.
Cursor will refactor its way across a codebase while you make a coffee. Claude will hold a proper architectural discussion and then implement the outcome. Lovable and Bolt will take a paragraph of plain English and hand back a working product that would have taken a small team most of a month in 2015. GPT will then explain the whole thing to your project manager in bullet points.
Even vibe coding, describing what you want and steering by feel while the AI drives, is a perfectly legitimate way to explore an idea. I’ve vibe-coded prototypes that would have died on the whiteboard a few years ago, simply because finding out now costs an afternoon instead of a month.
So no, I don’t think the weekend builders are doing anything wrong. I remember what a weekend of progress looked like in 1996. Mostly it looked like fighting an installer, and if things went really well, you finished with a login screen and a sense of cautious optimism. What these tools compress into two days used to be a quarter of somebody’s year.
The problem is not what these tools do. The problem is what we’ve quietly started assuming they do.
Writing code was never the hard part
Here’s a confession from three decades of commercial development. Typing the code was never the hard bit. It was usually the fun bit, which is a different thing entirely.
The projects I’ve watched fail did not fail because the code was bad on day one. They failed because of everything wrapped around the code. Architecture that couldn’t survive its third change of direction. Security bolted on after an awkward phone call. A user interface that made perfect sense to the person who built it and nobody else.
Then there’s the properly invisible stuff. Monitoring, so you hear about a problem before your customers do. Logging, so that 2am detective work involves evidence instead of guesswork. Tests that catch the regression before the release does. Disaster recovery, rehearsed and proven, because a backup you’ve never restored is a rumour. App Store compliance, which changes under your feet roughly once a year. Accessibility. Localisation, if you’d like customers beyond your own postcode. Subscription billing and its endless edge cases. Customer support.
I’ve inherited more than one system where the original code was, frankly, fine. What was missing was everything else. No logs worth reading, no tests, a schema held together by folklore, and a deployment process that lived entirely in one departed developer’s head. The code was never the problem. The code had been finished for years.
Which brings me to the distinction this whole article hangs on. AI has removed most of the cost of writing code. It has removed none of the responsibility of owning software. And ownership, not code, is where trust is earned.
The first version is the easiest version
There’s a truth about software that only reveals itself with time. The first version of an application is the easiest version you will ever build.
Version one is a blank page, and it’s exciting precisely because everything is new. No customers to disappoint, no data to protect, no earlier decisions to honour. You can rename anything, redesign anything, throw the schema out on a whim, and nobody feels a thing.
Version two has to respect version one. Version ten has to respect nine years of customer data, a database design that seemed clever at the time, and that one feature you’d love to remove except three hundred people quietly depend on it. Every release adds weight. Migrations that must carry every customer’s records forward without losing a single row. Backwards compatibility, so the customer who hasn’t updated since March isn’t punished for it. Old decisions that can’t simply be deleted, because deleting them breaks somebody’s Tuesday.
The first version is programming. Version twenty-seven is engineering. And the distance between them is the difference between writing software and owning it.
AI is spectacular at version one. That’s exactly what it collapses from months into a weekend. Nobody has yet built a tool that shoulders version twenty-seven for you, because version twenty-seven isn’t a coding problem. It’s a stewardship problem.
What I’m actually deciding on ShedBase
I can make this concrete, because I’m living it right now.
I’m building ShedBase with AI at my elbow the whole way. Claude has written thousands of lines of it. Good lines, mostly. If my job were “produce code”, I could knock off at lunchtime.
But when I look back over my notes from the last couple of months, almost none of my real decisions have been about code. How should sync behave when someone edits the same record on two devices? Should cloud storage be a subscription, and if so, what happens to a customer who stops paying? Do they lose access to their own data? What does the app do when Azure is having a bad day? Who owns the customer’s data, legally and practically? How do restores actually work, and have I rehearsed one lately? How do I migrate the database next year without breaking the records people entered this year?
And then the uncomfortable one, which I’d suggest every solo developer writes on a sticky note. What happens to my customers if I stop developing this?
Some of those questions have cost me a full week of thinking while Claude sat there, patiently, ready to generate either answer. That’s the strange new shape of this job. The implementation is nearly free. The decision is as expensive as it ever was, because the decision is where the responsibility lives.
The flood is coming
Here’s a prediction that doesn’t require much courage. We’re about to see more new apps launched than at any point in the history of software.
This won’t happen because AI writes poor software. Quite the opposite. It’ll happen because AI lets one person pursue ten ideas in the time it used to take to pursue one. Every developer I know has a drawer full of “someday” projects, and AI just unlocked the drawer. Several of mine are out and blinking in the daylight as we speak.
But sit with that arithmetic for a moment. A great many of those apps will not be here in three years, and very few will die because they were badly written. They’ll die because life happened to their developer. A new job. A new baby. Money running short. Interest running out. Idea number four of the ten, suddenly more exciting than idea number three. The subscriptions stop covering the Azure bill, or an API changes its terms one Tuesday, and nobody is home to fix it.
None of this requires a villain. Nobody in that story did anything wrong. Abandonment is rarely a decision. It’s the absence of one, repeated monthly until the hosting lapses.
And the customer never sees it coming, because the customer never thinks about the developer’s life at all. Why would they? Nobody installs an app wondering whether its creator will still care about it after the baby arrives.
We used to judge software by how hard it was to build. I suspect we’re about to start judging it by how hard it is to abandon.
The numbers behind the gold rush
And this isn’t just a feeling. The volume of software being produced is genuinely accelerating, and for once we can measure it.
Apple’s App Review team looked at more than 9.1 million submissions in 2025. Roughly 600,000 new apps actually made it onto the store that year, already a sharp jump on the year before. Then 2026 arrived: about 560,000 new apps in the first six months alone, putting the App Store on track to add close to a million new apps in a single year. The analysts tracking the surge point straight at AI coding tools. Apple, rather diplomatically, says the wave “reflects the relevance of the App Store”. Both things can be true.
But let me be precise about something, because it matters. The number of new apps is not the problem. More people building software is a good thing, and I’ll happily die on that hill. The hidden cost lives somewhere subtler.
Twenty years ago, hobby software looked like hobby software. The layout was slightly off, the icon was slightly homemade, and the description read like it was written at midnight, because it was. None of that made it bad software, but it was honest labelling. A refined interface meant a team had spent months on it, and behind that team sat testers, release processes and someone whose actual job was worrying about backups. Polish correlated with maturity because polish was expensive.
That correlation just broke. AI will now produce the beautiful interface, the professional icon, the attractive screenshots, the compelling store description and the confident marketing copy, all before lunch. What it produces none of, because nobody thought to ask, is the operational maturity those things used to imply. The rehearsed restore. The monitoring. The migration plan. The intention of still being here in year three.
Which means a customer standing in the app store can no longer tell the difference between an application backed by a sustainable software business and an application built by one enthusiastic developer over a single weekend. That’s not a criticism of the solo developer. I am one. It’s simply that visual polish is no longer a reliable signal of engineering maturity, and polish is the only signal a customer ever gets to see.
A beautiful interface creates confidence long before trust has been earned. That gap used to take years to open. It can now be generated in a weekend.
The person on the other end
This is the part of the conversation the internet keeps skipping, so let’s not.
People don’t install apps. They move in. They hand over years of memories, records, photographs, receipts, warranties, inventories, the paperwork of a small business, the story of a family. This one is personal for me, because keeping track of the things people care about is exactly what ShedBase is for. My customers will be trusting me with years of careful, patient data entry. That thought sits on my shoulder during every design decision I make.
Consumers assume software is permanent, and it’s a reasonable assumption. Nobody backs up their banking app. Nobody exports their email every Friday, just in case. We’ve been trained, correctly, to expect that serious software simply keeps working. That expectation is now being extended, invisibly, to weekend projects wearing professional polish.
So when a weekend app quietly dies, the customer doesn’t lose software. Software is replaceable. They lose the record of everything they own. The proof of the business they spent a decade building. The photographs of a workshop their father built. They lose a small piece of their own history, and they lose it without ever having been told the risk existed.
Build things anyway
If you’ve read this far and concluded I want fewer people building software, then I’ve written it badly.
I want more people building software. Some of the best products I’ve ever seen came from one person with a specific itch and no committee to talk them out of scratching it. AI has handed those people the best tools in history, and that deserves to be celebrated properly.
What I want is for more builders to think past launch day. The good news is that the entry fee is mostly better questions. Can my users get their data out, in a useful format, whenever they like, without asking me? What happens when, not if, my cloud provider has a bad week? If I walk away from this in two years, what does that look like for the people who didn’t?
Funnily enough, AI is superb at this too. The same Claude that writes my Blazor components will happily pressure-test a backup strategy or draft a data export feature. It just won’t raise the subject on its own. The tools have no opinion about whether you build something durable or something disposable. That part is still on us.
There’s a quieter commercial point here as well, for the consultants and small software companies reading. In a world being flooded with weekend apps, “we’ll still be here, and so will your data” may become the most valuable sentence in the industry. The gold rush crowd is optimising for launch day. The opportunity is in every day after it.
The easiest day
Thirty years in, this is the pattern I keep coming back to.
The day you publish an app is the easiest day it will ever have. No users yet, no data, no history to honour. Every day after that, the job quietly grows. Another customer. Another year of records. Another small promise added to the pile.
The tools are extraordinary, and I’ll be using them again tomorrow morning. And somewhere out there, someone is typing years of their life into an app built in a weekend, trusting, without ever thinking about it, that somebody is still holding the other end.
Publishing software has never been easier. Earning trust hasn’t changed at all.
Launch day isn’t the finish line. It’s the day the promises start.