TL;DR
- AI made software cheap to build — which means far more software exists, and all of it still needs an owner after launch.
- Ownership is contractual, not technical: you should hold the repo, every account, and the documentation, regardless of how much AI wrote the code.
- A real handoff package lets a competent stranger run the system. If it doesn't, you don't own your software — you rent access to whoever built it.
- Four support models work (in-house, builder retainer, third party, hybrid). What fails is the fifth: nobody, decided by default.
Here's the question nobody asks during the exciting part of a software project: who takes the call when it breaks at 9am on a Tuesday in two years? AI-assisted development has made building software so fast and cheap that thousands of companies now own custom apps for the first time — and many of them have no answer. This post is the answer, in four parts: what maintenance really is, who owns what, what a proper handoff contains, and which support model fits you.
What Maintenance Actually Involves
"Maintenance" sounds like mowing a lawn. It's closer to owning a building: mostly quiet, occasionally urgent, never optional. Concretely, a living application needs:
- Dependency and platform updates. The libraries, frameworks, and APIs your app sits on change constantly; security patches can't wait for a convenient quarter.
- Monitoring and incident response. Someone has to know the app is down before customers say so, and have the access to fix it.
- Backups that restore. An untested backup is a hope, not a plan.
- Small fixes and small features. The steady stream of "can it also..." that keeps software matched to the business.
- Cost and vendor hygiene. Renewing domains and certificates, watching cloud bills, rotating credentials when people leave.
None of this is exotic. All of it fails silently when unowned — usually discovered the week the certificate expires or the API your invoicing depends on gets deprecated.
Ownership: The Part to Get in Writing
AI writing the code changes nothing about ownership — the contract does all the work. The standard you should insist on: the client owns the code and the repository, holds every account (hosting, domain, database, email, third-party APIs) in its own name or with full transfer rights, and receives the documentation as a deliverable, not a favor. Red flags worth walking away from: a vendor who keeps the only copy of the repo, accounts opened under the vendor's email with no transfer clause, or "source code available on request" — which too often means available while relations are good. This is doubly important for founders who validated an idea by prompting an app into existence themselves; as we covered in vibe-coded vs engineered software, code nobody reviewed is risky, and code nobody owns is worse.
The Handoff Package: A Checklist
Whether you're leaving a vendor, hiring your first engineer, or just protecting yourself, the test of a handoff is simple: could a competent developer who has never met the builder take over from the package alone? That requires: full repository access with history; credentials for every environment moved to accounts you control; a README that gets a developer running locally in under an hour; an architecture overview (what talks to what, and why); documented deploy and rollback steps; the environment-variable list; tested backup-and-restore instructions; and an honest tour of known issues. One modern advantage: AI tools have made producing this documentation nearly free, so "we didn't have time to document" is no longer an acceptable excuse from any builder.
Four Support Models That Work
| Model | How It Works | Best For | Watch Out For |
|---|---|---|---|
| In-house | Your own technical staff own the system day to day | Software that is core to the business and changes weekly | Key-person risk if it's one part-time person |
| Builder retainer | The team that built it keeps a monthly engagement | Most small and mid-size companies; fastest fixes, full context | Verify the handoff package exists anyway — retainers end |
| Third-party takeover | A different dev shop assumes support | When the original builder is gone or underperforming | Expect a paid onboarding period; quality of docs decides its length |
| Hybrid | Internal owner for operations; specialists on call for changes | Stable systems with occasional feature bursts | Define clearly who is on the hook for incidents |
The failure mode isn't picking the wrong row — it's never picking one. Decide before launch, not after the first outage.
How AI Changes Maintenance (and How It Doesn't)
The good news: AI has cut the cost of every routine maintenance task. Dependency upgrades that consumed afternoons are drafted in minutes; an unfamiliar codebase can be explained instead of reverse-engineered; regression tests write themselves under supervision. This is the same leverage that makes legacy modernization tractable — reading and safely changing existing code is exactly what AI is best at. The unchanged news: judgment doesn't automate. Someone still notices problems, decides priorities, and reviews changes before production. Budget structure beats guesswork here — a small fixed keep-alive cost, plus variable spend on improvements. At MadXR every build ships with 30 days of post-launch support and a full handoff package, with ongoing support scoped to the system — see our published pricing for how engagements are structured.
Frequently Asked Questions
Who owns the code when a vendor builds software with AI?
Whatever the contract says — so make it say the right thing. The client should own the code, the repository, all accounts (hosting, domains, databases, third-party services), and the documentation. AI involvement in writing the code does not change this; the vendor assigns its rights to the work product the same way it always has. Walk away from any arrangement where the vendor keeps the repository or holds accounts in its own name with no transfer clause.
What should a software handoff package include?
At minimum: full repository access with history, credentials for every environment and service transferred to accounts you control, a README that gets a new developer running locally, an architecture overview, documented deploy and rollback steps, the environment-variable list, backup and restore instructions that have been tested, and a run-through of known issues and quirks. If a competent developer could not take over from the package alone, the handoff is not done.
How much does software maintenance cost per year?
There is no honest universal number — it depends on how much the software changes and what it integrates with. The structure is more useful than a figure: expect a small fixed base (hosting, monitoring, dependency updates, backups) plus variable cost driven by how many changes you request. A stable internal tool costs little; a customer-facing product that evolves monthly costs meaningfully more. Ask any vendor to split their quote into keep-alive versus improvements, and be suspicious of anyone quoting a big number without that split.
Can AI maintain the software it wrote?
AI makes maintenance dramatically cheaper, but it does not make it automatic. AI tools excel at the routine work: dependency upgrades, reading unfamiliar code, drafting fixes, writing regression tests. What still needs a human is noticing that something is wrong, deciding what should change, and reviewing what the AI proposes before it touches production. Maintenance in 2026 is a human owner using AI leverage — not software tending itself.