White-label DevOps for agencies: a handover checklist for AI-built client apps

White-label DevOps for agencies means an outside engineering team does the checks, setup and upkeep on your client apps while your agency stays the name the client sees. It is useful when your team builds client apps fast with Lovable, Bolt, v0, Cursor or Replit, but nobody in-house owns what happens after the preview: accounts, secrets, backups, deploys, alerts and the bill. The work is mostly a repeatable handover checklist plus someone who answers when the app breaks at a bad moment.

This post gives you that checklist in the order we run it, explains which items most often fail on AI-built client projects, and shows how to decide whether to keep the work in-house or hand it to a partner. If you already know you want help behind your brand, our white-label DevOps for agencies page explains how we work with agencies.

Why AI-built client apps need a different handover

Traditional agency handovers assumed a developer wrote the code and knew where everything lived. With AI builders, the person who "built" the app may be a designer or a project manager who prompted it into existence. That is a real productivity gain. It also creates three predictable gaps:

• Ownership gap. The project, database and hosting often sit in a team member's personal account because that is where the builder was logged in.
• Knowledge gap. Nobody can say with confidence which secrets exist, which tables are protected, or how a deploy actually happens.
• Support gap. After handover, every question goes back to whoever sold the project, because there is no runbook and no monitoring.

None of these show up in a client demo. All of them show up the first time the app has a real problem.

White-label DevOps for agencies: the handover checklist

Run these in order. Each section has a pass condition so your team can tick it off without guessing.

Stage 1: Ownership (before the client sees "final")

1. Code in the client's organization. The repository lives in a GitHub organization the client owns, with your agency added as a collaborator. GitHub supports transferring a repository between accounts and organizations, and issues, pull requests and history move with it. *Pass:* the client is an owner of the repo, and no personal account is the only admin. 2. Hosting in the client's team. Vercel, Netlify or similar projects belong to a team the client controls. Vercel documents how to transfer a project between teams. *Pass:* the client can see deployments and billing without asking you. 3. Database and auth in the client's account. Whatever backend the builder used (Supabase, Firebase, Lovable Cloud, a managed Postgres), the project and billing are in the client's name. *Pass:* removing your agency's access would not delete or lock the data. 4. Domain and DNS. The domain registrar account and DNS (for example Cloudflare) belong to the client. *Pass:* the client can log in and see the records. 5. Access list written down. One page that lists every service, who owns it, and who has admin access. Our post on owning the repo, environments and billing has a longer version of this list.

Stage 2: Security basics (before real users)

6. Secrets inventory. List every API key the app uses and where it is stored. Server-only keys (payment secret keys, database service keys, AI provider keys) must never appear in browser code. *Pass:* a search of the built JavaScript for key prefixes finds nothing secret. Our post on secrets leaking into the browser shows how to search. 7. Second-account test. Sign up as two different users and try to open each other's records, including by changing IDs in the URL. *Pass:* neither user can see the other's data. 8. Admin pages behind a role, not a hidden link. *Pass:* a normal user who types the admin URL gets refused by the server, not just a blank screen. 9. Payments verified server-side. If the app takes money, paid status changes only after a verified webhook, never because someone visited a success page. 10. Dependency alerts on. Turn on Dependabot alerts (or your platform's equivalent) in the client repo so known vulnerable packages are flagged. *Pass:* alerts are enabled and someone is subscribed to them.

Stage 3: Release process (before the second change request)

11. Protected main branch. GitHub branch protection can require a pull request and passing checks before changes reach the main branch. *Pass:* nobody, including an AI agent with repo access, can push straight to production. 12. Separate preview and production environments. Environment variables differ between preview and production, and test payments never touch live keys. Vercel documents preview and production environments separately. *Pass:* a preview deploy cannot write to the live database. 13. A smoke test after every deploy. Five minutes: sign in, create a record, view it as a second user, run a test payment if relevant. *Pass:* the steps are written down and someone runs them.

Stage 4: Running it (before you invoice the final milestone)

14. Backups restored once. Restore the latest database backup into a separate copy and confirm real records are there. *Pass:* you know how long a restore takes. 15. Uptime and error alerts. A simple uptime check on the home page and the sign-in page, plus error alerts, sent to a shared inbox or channel rather than one person. *Pass:* a test alert reaches the right people. 16. Bill alerts. Spend alerts or caps on hosting, database and AI providers in the client's accounts. *Pass:* a runaway bill would trigger an email before it becomes a crisis. 17. One-page runbook. Where things live, how to deploy, how to roll back, who to call. *Pass:* someone who did not build the app can follow it.

How to run the checklist on your next client project

You do not need to finish all 17 items on day one. A workable rhythm for an agency:

• At kickoff: create the client's GitHub organization, hosting team and database project first, then build inside them. Stage 1 then costs almost nothing.
• Before the client demo: run Stage 2 items 6–8. These are the ones that embarrass agencies most when a client's customer finds them.
• Before go-live: finish Stage 2 and Stage 3.
• Before the final invoice: finish Stage 4 and hand over the runbook.

If your team builds several client apps a month, turn this list into a template in your project tool, so each project gets the same checks rather than whatever the project manager remembers.

Keep it in-house or white-label it?

Keeping the work in-house makes sense when you have at least one person who enjoys infrastructure, has time protected for it, and will still be at the agency next year. It also makes sense when your clients are few and their apps are simple.

A white-label partner makes sense when:

• Your team is strong at design, product and prompting, but nobody wants to own servers, secrets and backups.
• You sell several AI-built apps a quarter and the support load is landing on the founders of the agency.
• Clients are asking for ongoing care after launch, and you want to offer it without hiring.
• You want a written check before handover that you can show the client under your own brand.

Whichever way you go, the questions to ask a partner are simple: Will the client's accounts stay in the client's name? Will you work under our brand and only talk to clients if we ask? What do you check before handover, and can we see an example report? How do you handle access when a client leaves?

Common failure patterns on AI-built client apps

These come up again and again in agency work, and each maps to a checklist item:

• The builder's account is the only owner of the database. When that person leaves the agency, nobody can reach the backend (items 1–5).
• A secret key was pasted into a prompt and ended up in front-end code (item 6).
• "Admin" was a hidden menu item, not a server-side role (item 8).
• An AI agent pushed a large change directly to production because the branch was unprotected (item 11).
• Backups existed but had never been restored, and the restore took far longer than the client expected (item 14).

Quick checklist

• Create client-owned accounts at kickoff, not at handover.
• Inventory secrets and run the second-account test before any demo.
• Protect the main branch and separate preview from production.
• Restore a backup, turn on alerts and set bill caps before the final invoice.
• Hand over a one-page runbook.
• Point clients to the free self-check for a quick traffic-light view before you book a deeper review.

FAQ

Does a white-label partner talk to my clients?

With us, only if you ask. The usual arrangement is that your agency stays the face of the work, and reports can carry your logo.

Can we use this checklist without hiring anyone?

Yes. It is written so an agency team can run it themselves. A partner helps when you want the checks done consistently across many projects, or when nobody in-house owns infrastructure.

Which AI builders does this apply to?

All of them. The tools differ in where they put the code and the database, but ownership, secrets, access control, releases, backups and alerts are the same questions for Lovable, Bolt, v0, Cursor and Replit projects.

---

Your clients buy the app from you, so the handover should hold up under your name. If you want checks, setup and care done behind your brand, read how our white-label DevOps for agencies service works, then book a free technical assessment. We will review one client project with you and give you a written next step.