The message usually reads something like this: “We built our new site with Lovable. It’s live and we love it. Can you take over maintenance and do the SEO?”
Two years ago that message did not exist. Now it arrives weekly. Lovable passed 2.3 million users, Wix bought Base44 and put the same idea in front of 300 million accounts, and Replit, Bolt and v0 are all growing at rates that used to be reserved for social apps. A dentist, a roofer or a two-location clinic can describe a website in plain English on Friday and have it online by Sunday.
I think that is mostly good. The sites often look better than what a template builder produced, and the owner understands their own site for the first time. The problem is not that the site was built with AI. The problem is that nobody has decided who owns it, and “take over maintenance” quietly makes that person you.
So I treat the handoff as a project of its own, with a fixed time box, a written result and a decision at the end. This is the intake I run before anyone on my team touches the site, and it is the same one I would want an agency to run if I were the owner.
Why “just maintain it” is the most expensive sentence in web
When a client hands you a site, you are not inheriting a design. You are inheriting every decision a model made under time pressure, with no reviewer, for someone who could not read the output. The research on what that produces is now solid.
Industry figures, not a single client. The point is the base rate: a site you have never seen has roughly even odds of carrying at least one of these.
Those numbers explain why the word “maintenance” is dangerous. Maintenance implies the thing is sound and only needs upkeep. If one in five of these builds has a live key sitting in the browser bundle, the first month of “maintenance” is really a security remediation you did not scope, did not price, and are now responsible for. The OWASP Top 10 was updated in 2025 to make software supply chain failures a category of its own, which covers exactly this pattern: a model inventing a package name, and someone else registering it.
None of that is an argument against taking the work. It is an argument for finding out what you are taking before you say yes.
The handoff is a project, not a favor
Here is the frame that keeps this from turning into an open-ended favor. The intake gets a time box of one working day, a fixed set of gates, and one deliverable: a one-page memo with a recommendation. The client pays for that day. If they will not, that tells you something too.
If you read my audit of a surgery clinic’s website, you know I normally review a site in the order a visitor experiences it: design, then UX, then content, then technical, then analytics. For an inherited AI build the order flips. Ownership and security come first, because there is no point polishing a home page that is leaking a payment key. The visitor path is still in there. It comes last, and it usually gets the most attention once the site is safe.
The six gates
Each gate has one question I need answered, a short list of what I look at, and a red flag that ends the gate early. You do not need to be a developer to run most of this. You need access, a checklist, and the discipline not to skip ahead to the fun part.
1Ownership and access
Who can log in, and where does the code live?
Builder account owner, domain registrar, DNS, hosting, the database, and any third-party services (payments, email, booking). Whether the code can be exported to a repository the client controls, or only exists inside the builder.
Red flag The site lives in a personal account that belongs to a nephew, a freelancer, or someone who left.2Secrets and authentication
Is anything sensitive reachable from a browser?
Search the shipped bundle for API keys, tokens and connection strings. Check whether the database rules allow public reads or writes. Try the admin and dashboard paths logged out. Confirm passwords are hashed and sessions expire.
Red flag A live payment or email key in client-side code. Stop, rotate it, then continue.3Dependencies and hosting
What is this built on, and does all of it exist?
List every package and confirm each one is real, maintained and current. Check the framework version. Note where it is hosted, what the plan costs, what happens at the traffic or storage limit, and who gets the bill.
Red flag A package name that returns nothing on the registry. That is a supply chain hole, not a typo.4Data and privacy
What personal information does the site collect, and where does it go?
Every form, upload and booking flow: what is stored, where, for how long, and who gets notified. Consent banner and privacy policy present and true. For a medical, legal or financial business, whether any of it needs a signed agreement with the vendor.
Red flag Patient or client details in a database with no access rules and no retention plan.5Backups, deploy and change control
If this breaks on a Friday, how do we get yesterday back?
Automated backups and a tested restore. A staging copy separate from the live site. Version history for the code. A way to publish a change that does not involve re-prompting the builder and hoping the rest of the site survives.
Red flag The only copy of the site is the live one, and the only way to change it is a new prompt.6The visitor path
Can a customer find it, use it, and reach a human?
The normal audit, compressed: does it show up in Google, is the phone tap-to-call on mobile, do the forms deliver, is every action being counted. AI builds are strong on looks and weak here, because the model never met the customer.
Red flag No analytics, no form notifications, or a call button that goes to voicemail after 3 pm. Here is what that costs.What turns up
Because I am writing this from industry data rather than a single client, I will give you the composite. These are the findings that repeat across the published scans and across the handoffs agencies describe, in roughly the order they appear. Treat the table as a menu of what to expect, not a promise of what you will get.
| Finding | Why it happens | What it usually means |
|---|---|---|
| Keys in the bundle | The builder put the key where the prompt asked for the feature. Nobody split client from server. | Harden Rotate today, move server-side this week. |
| Open database rules | Default Firebase or Supabase rules left permissive so the demo would work. | Harden Rules plus an audit of what was already read. |
| Admin with no login | Auth was described in the prompt, not implemented; the route exists, the check does not. | Harden Real auth, or remove the route. |
| Invented packages | Model hallucinated a name, and a third party may already own it. | Rebuild if it is in the payment or auth path. Replace otherwise. |
| No repository | Code exists only inside the builder’s project. Nobody set up an export. | Harden Export to a client-owned repo before any other change. |
| No backups or staging | The builder is the staging. Every prompt edits production. | Harden Backups first, staging second, then a change process. |
| Forms that go nowhere | A free-tier form service, no notification, or a mail function that silently fails. | Maintain Fix the wiring and test it monthly. |
| Nothing measured | Analytics was never requested, so it was never built. No calls, forms or bookings counted. | Maintain Tag manager, events, call tracking, one dashboard. |
| Thin, lookalike content | The model wrote what every site in the category says. Nothing that only this business could say. | Maintain Content is a project, not a fix. Scope it separately. |
Notice the pattern. Most findings land in the middle column. Very few AI builds need to be thrown away, and very few can be taken over as-is. The typical answer is a short hardening project followed by a real maintenance agreement, and the intake is what lets you price both with a straight face.
The fork: maintain, harden or rebuild
The memo ends with one of three words. Here is how I get there, in the order I ask the questions. The first “yes” that fits decides it.
A note on rebuilds, because it is where inherited sites go wrong twice. If the answer is rebuild, the new site has to inherit the old one’s URLs, rankings and tracking, or you have traded a security problem for a traffic problem. That is a migration project with its own checklist. In the Chicago garage door rebuild we mapped every old URL before launch; 39 of 40 were redirected or deliberately retired on day one. Do that, or do not rebuild.
What the client reads
The owner does not get the checklist. They get one page, written so a person who has never heard the word “repository” can make the decision. It has five parts, in this order.
The one-page memo
- What we found, in plain language, worst first. “Your payment key is visible to anyone who views the page source” beats “secret exposure in client bundle.”
- What it risks, in business terms. Fraud on the card account, a patient-data complaint, a weekend outage with no way back.
- What we recommend, as one of the three words, with the reason.
- What it costs and how long, as a fixed scope for the hardening or rebuild, and a monthly figure for maintenance. Two numbers, not a menu.
- What we need from you, which is almost always access, account ownership, and a decision by a date.
Written this way, the memo does two jobs. It protects the client, because they now know what they own. And it protects the agency, because the scope of “maintenance” is on paper before the first invoice.
Where the team comes in
I run the intake alone, because it is faster and because the point is a decision, not a build. Once the memo is accepted, the work splits the way it always does. A developer takes gates two, three and five: rotate, export, add auth, set up backups and staging. A content writer takes the lookalike copy problem, which is usually the largest single lift on an AI build. The SEO specialist takes gate six with me: tracking first, then the migration plan if we are rebuilding. We meet weekly, and the first report the client sees is not a list of vulnerabilities closed. It is calls, forms and bookings counted, because that is the number the owner asked about before any of this started.