AIGuide
daLæs på danskAI-Generated Code After 12 Months: What Does Maintenance Cost?
Maintaining AI-generated code gets pricier every month without a plan. See what duplicated logic, missing tests and stale packages cost you by month 12.
Freelance full-stack developer
- Published
- Reading time
- 11 min
In this post8
Maintaining AI-generated code costs very little in the first few months and more with every month that passes without a plan. Three problems grow quietly in the background: duplicated logic, no automated tests and dependencies that fall out of support. By month 12, a one-off cleanup often costs more than a year of steady maintenance would have.
I sell maintenance work myself, so weigh my view accordingly. It's also why there's a section below on when you don't need it.
The short answer: how the first 12 months play out
| No maintenance | Ongoing maintenance | |
|---|---|---|
| Months 1-3 | Everything works, and small changes are quick to prompt | Critical flows get tests, and dependencies and security are reviewed |
| Months 4-6 | Fixes start breaking other parts of the app | Small monthly updates, plus cleanup whenever a feature is touched |
| Months 7-9 | Packages with known vulnerabilities, and nobody dares to update | Security patches applied within days |
| Months 10-12 | New features take far longer, and a cleanup or rewrite is looming | A change costs roughly what it did at the start |
Treat the table as a typical pattern, not a law. The pace depends on how often the app changes. An app nobody touches decays slowly. One that gets new features every week can reach the month-12 state in half a year.
My rule of thumb: if the app has real users or holds data you can't afford to lose, it needs a maintenance rhythm from the day it goes live. If it isn't live yet, start with my guide to taking a vibe-coded app to production. This post is about what happens after launch.
Why AI-written code gets harder to own
Lovable, Bolt and Cursor solve the task you give them right now. That's their strength. But every prompt is solved in isolation, and nothing holds the full picture of the codebase. When the tool needs something similar to existing code, it often writes a fresh version instead of reusing the old one.
You can see this in the data. GitClear analyzed 211 million changed lines of code from 2020 to 2024. Lines classified as copy/pasted rose from 8.3% to 12.3%, while moved lines, which usually signal refactoring, fell from 25% in 2021 to under 10% in 2024. The numbers are in GitClear's research on AI assistants and code quality.
Google's 2024 DORA report points the same way. Increased AI adoption was accompanied by an estimated 7.2% drop in delivery stability, according to Google's summary of the DORA report. The report's explanation: AI doesn't replace the basics, such as small batches and solid testing.
Both studies look at professional developers who read and approve code before it ships. In an app built purely by prompting, nobody does that review, so in my assessment the effect is stronger. The code can be perfectly fine on day one. The trouble is that it gets worse with every change if no one tidies up.
The three problems that compound
The three problems tend to show up together, and each one makes the others more expensive.
Duplicated logic
Duplicated logic means the same business rule lives in several places. In month one that's harmless, because every copy does the same thing. The trouble starts when a rule changes.
Say your checkout and your invoices each calculate VAT. You start selling to customers in another EU country, ask the AI tool to handle the new rate, and it updates the place it can see. Checkout now charges one amount and the invoice states another. If the duplicated rule decides who can see which customer's records, a missed copy isn't a bug anymore. It's a data leak.
This is what sits underneath the familiar prompt loop, where one fix creates two new bugs. I've listed the warning signs in when to stop prompting and hire a developer.
No automated tests
Automated tests are small programs that check the app still does what it should: a user can log in, a payment gets recorded, an invoice shows the right total. They run in minutes every time the code changes.
AI tools rarely write tests unless you ask, and when you build by prompting, you test by clicking around. That works while the app is small. A year in, there are too many flows for anyone to check by hand before every change, so nobody does. Your users find the bugs instead.
Missing tests also make the other two problems more expensive. Without tests, consolidating duplicated logic and updating dependencies are both risky, so both get postponed.
Stale dependencies
A modern web app is assembled from packages: ready-made libraries for login, dates, payments and the user interface. Count the packages those packages depend on, and you're often into the hundreds. They all release new versions, and old versions stop getting fixes.
Frameworks have fixed end dates. Laravel's support policy gives each major version 18 months of bug fixes and 2 years of security fixes. Many JavaScript packages ship major versions even more often. Within 12 months, some of the packages in a typical app will have new major versions, and some may get public security advisories.
AI tools can also suggest versions that were current when the model was trained, so your app may be behind on launch day. With no tests, nobody wants to update, and the gap widens every month. Outdated and hallucinated packages are a security issue too, which I cover in the most common security issues in vibe-coded apps.
What maintenance costs: a rough 12-month comparison
For conventionally built apps, my rule of thumb is to budget 10-20% of the original build cost per year for maintenance. That rule breaks for AI-built apps, because the build cost was low. If the app cost a subscription and a few evenings, a percentage of that tells you nothing. Budget in hours instead.
According to Lancebase's overview of freelance developer rates in Europe, full-stack freelancers in Western Europe typically charge around €75-120 an hour. Senior specialists can charge more. Using those rates, here's a rough comparison for a small app with paying users:
| Retainer from launch | No maintenance for 12 months | |
|---|---|---|
| Ongoing work | Assumed 3-6 hours a month | None, until something breaks |
| First-year cost | Roughly €2,700-8,600 at €75-120 an hour | Close to zero at first, then urgent fixes at short notice |
| Urgent bugs | Less frequent, because tests catch many of them | Found by users and fixed in a hurry |
| At month 12 | An app you can keep building on | A cleanup measured in weeks rather than hours, or a rewrite |
| New features | Roughly the same cost as at launch | More expensive the longer you wait |
The hours are an assumption for the example, not a quote. A small app with few integrations can need less. One with payments, user roles and several integrations will need more. The main cost drivers:
- How often the app changes. Every new feature adds to the testing and cleanup work.
- Personal data and payments. Under GDPR Article 33, a personal data breach generally has to be reported to your data protection authority within 72 hours, and handling one costs far more than preventing it.
- Number of integrations. Every connection to another system can change without warning.
- How far behind the app already is. If maintenance starts after a year, you pay for the catch-up first.
The hidden cost is speed. Without maintenance, every new feature gets more expensive to build, and that comes straight out of your product budget.
How a maintenance retainer prevents the damage
A retainer is a fixed monthly agreement where a developer reserves a set number of hours for your app. What you're really paying for is the rhythm: small things get handled before they grow. A good retainer usually runs like this:
- Start with a baseline review. The developer lists packages and versions, known vulnerabilities, where logic is duplicated and which flows must never break. Everything else builds on that list.
- Add tests around the critical flows. Sign-up, login, payments and data creation come first. The goal is that the flows that earn you money are checked on every change. Full coverage can wait.
- Turn on automated alerts. Tools like GitHub's Dependabot propose updates as new versions are released. The developer reviews them, and tests run before anything goes live.
- Update on a schedule. Minor updates monthly, security patches immediately and major versions on a dated plan.
- Clean up where you build. Whenever a feature changes, its duplicated logic gets pulled into one place. The code improves where it's actually used, without a big-bang refactoring project.
- Report every quarter. A short written status on versions, incidents, known weak spots and next steps, so you always know where the app stands.
You can keep building features with your AI tool alongside the retainer. The difference is that the code lives in a repository your company owns, and a developer reviews changes before they reach production.
For what the contract itself should cover, such as response times, pricing and responsibility during downtime, see my guide to what a software maintenance agreement should include.
When you don't need a maintenance retainer
Not every AI-built app needs a standing agreement, and I'll say that even though I sell them.
- Your prototype has no real users yet. If you're still figuring out what the product should do, keep building. Code quality isn't your bottleneck.
- It's an internal tool for a handful of colleagues. If it works and holds no personal data, messy code can be good enough. Do patch packages with known security issues, though.
- You're going to rewrite it anyway. There's no point paying to maintain code you'll replace in a few months. If you're facing that decision, read my guide on whether to rewrite or refactor a vibe-coded app first.
- You have a developer in-house. Giving them time for maintenance usually beats bringing in an outsider, me included.
Next steps
If your app is already some way into those 12 months, start with an honest picture of where things stand rather than a big plan. The checklist below gives you one.
Is your AI-built app ready for the next 12 months?
- Ownership: the code lives in a repository your company owns.
- Tests: login, payments and other critical flows are tested automatically.
- Dependencies: you know which versions the app runs on and whether any have known vulnerabilities.
- Support: your framework and runtime still receive security fixes.
- Logic: key rules such as pricing, VAT and access control live in one place in the code.
- Rhythm: it's agreed who updates the app, and how often.
- Visibility: you've had a written status update within the last quarter.
If more than two of these are missing, it's time for a review. You can see how I handle maintenance and ongoing development of existing apps, including ones built with AI tools.
Frequently asked questions
What's the difference between a retainer and prepaid hours?
A retainer is a fixed monthly agreement with reserved hours and set tasks, such as updates, monitoring and a quarterly report. Prepaid hours are a block you draw on whenever you need help. A retainer guarantees the rhythm, while prepaid hours give you flexibility. For an AI-built app in production, I usually recommend a retainer for the first year, because the problems grow precisely when nobody is watching.
How many hours a month should I budget?
It depends on the app, and the best answer comes after a baseline review. Start with a cautious estimate and adjust after three months, once you can see where the time actually goes. If the hours go to urgent bugs rather than prevention, the retainer is too small or tests are missing. If hours sit unused every month, scale down.
Can another developer take over maintenance later?
Yes, as long as the code is in your own repository, has tests and comes with a short note on how to deploy it. A good retainer should leave you with all three. With me, you own the code from day one, so you can switch without asking permission. Also make sure every account for hosting, the database and third-party services is in your company's name.
Does it matter where my maintenance developer is based?
It matters most for data protection and working hours. If your app stores personal data about people in the EU, anyone with access to the production database processes that data on your behalf, so you need a data processing agreement wherever they are. An EU-based developer avoids extra questions about data transfers and shares your business hours. This isn't legal advice, so check the details with your own adviser.
Does this apply to code my developer writes with AI tools?
The mechanism is the same, but the risk is lower when a developer reads, tests and approves the code before it ships. Plenty of professional developers use AI tools today. Ask yours how AI-generated code gets reviewed and whether tests are written for it. A specific answer is a good sign. A vague one is a reason to ask more questions.