Writing software was always the cheap part. AI made exactly that part cheaper and left the expensive part untouched. What happens to a generated app over its first year in production, and how to work out in advance who carries it.
There's a sentence almost every small business owner hears these days: “AI could knock that out for you in an afternoon.” And it's true. The sentence just stays quiet about what comes next.
Writing software was never the expensive part. The expensive part is maintenance - all the years in which laws, processes and people change and nobody quite remembers why the code was written the way it was. AI made day one cheaper. It left the other thousand days exactly where they were.
One year in the life of a generated app
Picture a job-tracking app that AI generates for you in the spring. It works. Colleagues use it. And then time passes.
Day 1. Live. Everyone delighted, because it took two days instead of two months.
Month 2. The VAT rate changes on one item type. In the app it's hard-coded. Somebody has to find it and change it. That somebody is you, your nephew, or a person you pay to do it.
Month 6. A new colleague joins the back office. She needs to see only her own jobs. There's nothing like that in the app, because the original prompt said nothing about roles. Adding permissions isn't “one more prompt” - it's a change that has to hold across every screen.
Month 12. Something stops working. Whoever generated the app has left, or can't remember what's in it. They can read the code, but they don't understand it - a machine wrote it and nobody reviewed it properly.
Writing the app is the cheap part
On day one both routes look identical. The difference shows up in month two, month six and month twelve - and from there it only grows.
Why this happens almost every time
It isn't that AI writes bad code. The code is often surprisingly decent. The problem sits elsewhere, in three layers.
Nobody knows the code. With a conventionally written app there's at least one person who knows why something was done a particular way. With a generated app that person doesn't exist - there's only a prompt and an output.
Maintenance is invisible up front. When an agency builds your app, maintenance costs are in the quote. When you generate it yourself, they're nowhere - which doesn't mean they aren't there.
Changes don't arrive one at a time. A company shifts continuously: a new job type, a new rate, a new colleague, a new client requirement. Each of those changes is small. Twenty small changes a year is a month of work.
Three questions to ask before you start
Before building anything important on generated code, three concrete questions are worth asking:
- Who here will read this code when something breaks? If the answer is “nobody”, you don't have an app, you have a liability.
- How many changes do we expect in a year, and who makes them? Write them down. Most companies land on eight to twenty small items a year, and that's a standing commitment.
- What happens when that person leaves? With your own code that's a risk you carry. With a platform it's a risk the supplier carries.
This isn't an argument against using AI
AI is now a perfectly sensible way to design an app, describe it and have it built. The difference is whether what comes out is source code you have to look after, or an application running on a platform that takes maintenance, backups and updates off your hands.
What “the platform carries it” actually means
Specifically this: updates, backups, security patches and compatibility aren't your concern. When a rule changes, you change a field or an automation - and a non-technical person on the team can do it. When the person who built the system leaves, what remains is configuration anyone can read, not code nobody understands.
It doesn't mean a platform handles absolutely everything. For genuinely unusual logic there are escape hatches via webhooks and API. The difference is one of proportion: instead of owning the whole app, you own the one exception.
For a practical look at automation you can actually see inside, read Automation without the black box. And if you're weighing up specific AI builders, the comparison is in Lovable, Bolt, v0 and friends. An overview of the whole subject is in the complete guide to no-code and AI app development.
Common questions about maintaining AI-built apps
Can't AI just fix the app as well?
Partly, but you run into two things. AI needs to be told precisely what's wrong - and somebody has to work that out. And the second fix happens on code produced by the first fix, so with every round the risk of breaking something else goes up.
What does maintenance actually cost?
It depends on how often your process changes. A working figure from ordinary business apps: budget for ten to twenty small changes a year. When an external person handles them, that's a recurring line in the budget, not a one-off cost.
How do I stay in control if I have an app built for me?
Ask three things up front: who will make changes, what an hour of that person's time costs, and where the data will be stored. If a supplier has no answer to the last one, that's a sign nobody is thinking about maintenance.