Agency handover checklist before you bring work in-house

Why agency control becomes a risk

An agency can build quickly, but control often stays with the people who leave first. That becomes a business risk the moment you want to cut spend, change direction, or bring development in-house with AI support.

The first problem is dependency. Your team cannot ship without the agency. One agency developer may hold the only production deploy rights. Another may be the only admin on GitHub, GitLab, the cloud account, the app store, or DNS. That can seem harmless during normal work. On release day, it can stop sales, support, and customer trust within minutes.

The weak spots usually hide in boring details: a forgotten 2FA device, an inbox tied to a contractor, a CI secret nobody wrote down, or a build certificate stored on one laptop. The code can be ready and reviewed, yet the release still stalls.

Knowledge is the second risk. Many companies try to save money by cutting agency scope, then discover the agency still holds the map. Your team may have the source code, but not the release steps, rollback plan, background jobs, monitoring alerts, vendor approvals, or the full list of services that keep the product alive.

That gap gets expensive fast. Marketing plans a launch, but nobody on your side can publish the mobile update. A payment bug appears, but your team cannot find the right server or secret. Your in-house team fixes the issue, but nobody can deploy it safely.

AI makes this gap easier to see. An internal team can use AI to write code faster, review pull requests, and draft docs. AI cannot recover an account your company never owned. It also cannot guess missing release steps well enough to protect production.

Cost cuts fail when control stays outside the company. If the agency still owns repo admin access, production approvals, or release knowledge, you have not really brought the work back in-house. You have only changed who sends the invoice.

Real control starts with ownership. When your company holds the repos, release rights, credentials, and runbooks, you can reduce agency time without freezing delivery.

What to take back first

Start with anything that lets someone ship, block, or break production. If an agency still controls those parts, you do not fully control delivery, even if your team already has the code.

Many teams think source code is the whole handover. It is not. Code without admin access, release rights, and written steps is just a snapshot. You can read it, but you may not be able to deploy a fix when something goes wrong.

A good handover starts with ownership, not documentation. Take back the accounts and permissions that decide who can push changes live. In practice, that means repo ownership and admin rights first, then cloud accounts, DNS, mobile app store access, CI pipelines, build secrets, package registries, monitoring, backups, and restore rights. Only after that should you rely on written release and rollback instructions.

Repository access comes first because everything else depends on it. Make sure your company owns the main organization, not just a copied repo under an agency account. Check branch protections, deploy keys, webhooks, and who can approve merges.

Then move to infrastructure and identity. If the agency controls DNS, production hosting, or the app store listing, they still control your public product. This is a common mess: the in-house team fixes a bug in one hour, then waits three days because the agency owns the signing certificate and app store login.

After that, pull back the build and release chain. CI systems often hide the real working parts of a product: environment variables, tokens, signing files, private packages, and deploy scripts. If those stay behind, your new team wastes time rebuilding a process that already exists.

Do not skip observability and backups. Your team needs access to logs, uptime alerts, error reports, database snapshots, and restore steps on day one. When a release fails, that is how they find the cause quickly.

Keep the release and rollback runbooks short and plain. Teams often inherit systems that technically work, but nobody can explain the exact order for a safe deploy. That gap causes more delays than missing code.

If your team can ship, monitor, and roll back without asking the agency for help, control is back where it belongs.

Map every account and approval

Most teams know the code repo matters. They miss the smaller accounts that decide whether code can ship at all. One missed admin seat in DNS, cloud hosting, CI, app stores, or monitoring can stall a release for days.

Build one simple inventory before you ask the agency to hand anything over. A checklist only works if it covers every tool used for design, development, release, support, and billing.

Start with a table and include every service used to build or ship the product. That usually means source control, cloud accounts, deployment tools, domain registrar, DNS, package registry, app stores, analytics, error tracking, customer support, email delivery, payment systems, design files, and documentation.

For each tool, record four facts: what the tool does, which company pays for it, who owns the admin login today, and who can approve actions inside it.

Then go deeper on permissions. "Has access" tells you very little. You need to know who can merge to the main branch, deploy to staging, deploy to production, approve infrastructure changes, publish a mobile build, rotate secrets, change DNS, and roll back a bad release.

This is where hidden risk shows up. A repo may sit under your company name, but release control may still live with one agency engineer through a deployment token, app store approval, or protected branch rule. If that person is out, your team waits.

Move shared tools to company email accounts before you reduce agency scope. Use addresses tied to the business, not personal inboxes from agency staff or former employees. Billing notices, admin alerts, password resets, and security messages should reach your team first.

Then clean up approval paths. Remove personal accounts from required approver lists, production deploy approvals, and emergency rollback steps. Keep the agency involved for a short overlap if needed, but the final yes should belong to the company.

A small startup can have ten separate release gates without noticing. GitHub, cloud hosting, app stores, DNS, and error tracking alone can block a launch. Map them now so repo ownership transfer becomes a real handover instead of a false one.

Transfer control in the right order

A clean handover needs a short pause. Give yourself a one- or two-week window where the agency only fixes urgent issues and nobody starts large features. That lowers the odds of surprises and gives your team a stable target to take over.

Order matters more than speed. If you shrink the agency scope before your company owns the code, access, and release path, you can end up paying for emergency help later.

1. Move repository ownership to company accounts first. Put the main Git provider, admin rights, branch protection rules, and backup access under people on your payroll. Keep the agency in the repo for now, but as contributors, not owners.
2. Gather and rotate every secret. API keys, cloud tokens, signing certificates, deployment passwords, and webhook secrets should go into one company vault. Do not leave production credentials in agency laptops, chat threads, or private password managers.
3. Rebuild the release path under your control. Your team should own the build jobs, package registry, app store access, cloud deploy rights, and rollback steps. If releases still pass through an agency account, you do not control releases yet.
4. Test permissions in the real world. Ask your team to log in, trigger a test build, view logs, approve a deploy, and roll back in staging. This sounds basic, but it catches missing access before it blocks a live fix.
5. Ship one small production change with your own team watching. Pick a low-risk update such as copy text, a flag change, or a tiny bug fix. Let the agency observe if needed, but your team should press the buttons and follow the steps.

After that first release, remove access in stages, not all at once. Start with production deploy rights and secret access, then reduce admin roles in source control, cloud, monitoring, and third-party tools. Leave a short overlap for questions, with a named contact and a written response window.

This is also the right moment to write the release routine in plain language. A runbook should tell a tired teammate what to do at 7:00 a.m. during an outage. It should not read like internal marketing. Keep it short: where the code lives, who approves a release, how to deploy, how to roll back, and where to check logs.

Teams that want to bring work in-house with AI support often rush the staffing change and skip the transfer order. That is backward. First take control. Then trim agency scope. Then let your smaller team improve the workflow.

Write runbooks people will actually use

A good runbook helps a tired teammate do the right thing at the right moment. If a new engineer cannot follow it during a busy afternoon, it will fail during a real incident.

Start with the three tasks that create the most stress: deploy, rollback, and hotfix. Write the exact order of actions, not a summary. Name the repo, branch or tag, pipeline, environment, and the command or button the person must use.

Add timing next to each step. People need to know whether a deploy usually takes 8 minutes or 25, and whether a rollback should finish in 3. That stops panic when a job runs longer than expected.

What to include

Every runbook should include a few simple checks that confirm the system is healthy. Keep them measurable. Good examples are: the homepage loads and login works, the API health check returns 200, the error rate stays near its normal level for 10 minutes, queue size does not keep rising, and the latest release tag matches the version in production.

Then tell people where to look for evidence. Do not write "check the logs." Write where the logs live, which dashboard to open, which alert channel to watch, and what normal looks like. If your team uses Grafana, Sentry, Prometheus, or Loki, name the exact dashboard, project, or query.

Names go stale quickly. "Prod server" and "main dashboard" are not enough. Use the real system names and keep the commands current every time the agency or your in-house team changes tooling.

Test it with someone new

The best review is simple: hand the runbook to someone who did not write it and watch them use it. Do not explain anything at first. Every pause, guess, or wrong click shows you where the document breaks.

A small example shows the difference. "Run the production deploy" is vague. "Deploy api-service v2.14.3 in GitLab pipeline release-prod, wait for the migration job to finish, confirm /health returns 200, then watch the 5xx dashboard for 10 minutes" is usable.

If you plan to bring development in-house, treat runbooks as operating tools, not handover paperwork. When one person outside the agency can ship a hotfix and roll it back without asking for help, the runbook is ready.

What a clean handover looks like

A small startup decides to cut agency hours next month and bring day-to-day work in-house. The founder assumes the switch will be easy. Then she tries to prepare the next mobile release and finds out the agency controls the app store login.

That changes the plan quickly. If the agency owns the store account, they can block releases by accident, delay a hotfix, or simply disappear at the wrong time. The team pauses the cost-cutting plan for one week and focuses on control first.

They keep the scope tight. Instead of asking for "all documentation," they ask for the few things that let them ship safely: source repos, CI access, deployment secrets, app store credentials, and the current release checklist. That keeps the handover concrete and easy to verify.

Their week is simple. On day one, they move all code repositories into the company account and confirm admin access. On day two, they transfer CI pipelines and rotate secrets after the move. On day three, they move app store and cloud access to company-owned logins. On day four, they write the release and rollback steps into a short runbook. On day five, an internal engineer ships a small update.

That small update matters more than any meeting. The engineer changes a minor text string, runs the build, pushes the release, and watches the logs after launch. That test proves the company can ship without asking the agency for help.

The agency still stays on call for one backup cycle. That is a sensible middle step. If a certificate breaks, a billing permission goes missing, or an old pipeline job fails, someone who knows the history can answer quickly. After that cycle ends, the startup cuts agency scope with much less risk.

This is what clean repo ownership transfer looks like in practice. The company does not aim for perfect paperwork. It aims for one clear result: the internal team can release, fix, and roll back on its own.

Mistakes that cause delays

Most delays start with bad timing, not hard technical problems. A company cuts agency hours first, then finds out nobody inside can approve a release, log into the cloud account, or fix a billing issue. The code may be in your repo, but control is still elsewhere.

The most common mistake is reducing agency time before every access transfer is done. Keep a short overlap period while your team proves it can log in, deploy, roll back, and handle routine issues on its own. Paying for one extra week hurts less than missing a release because the only person with approval rights is no longer on the project.

Loose notes create the next wave of delays. "Deploy from CI" is not a runbook. Neither is "the config is in the cloud console." Your team needs exact steps, account names, approval points, and the order of actions. If someone cannot follow the notes during a normal workday, they will not manage them during an outage.

Billing ownership causes more trouble than many teams expect. Repo access gets attention, but cloud invoices, app store accounts, domain renewals, email platforms, and monitoring tools often stay under the agency or a former employee. Then a card expires, a payment fails, or a store asks for a code that nobody in-house can receive. Repo ownership does not help if finance access still sits with someone outside the company.

Old contractors also stay in admin groups far too often. Teams add new people during handover, then forget to remove the old ones. That creates confusion quickly. When something breaks, nobody knows who should act, and too many people still have power they no longer need.

The last mistake shows up right before the first solo release. The team assumes the process works because the agency shipped last week, so nobody tests rollback under internal control. That is a bad bet. Before you bring development in-house, run one practice release and one rollback drill with your own team.

Do not close the checklist when files arrive. Close it when your team can ship, undo a bad release, and pay every bill without asking the agency where anything lives.

Checks before you cut agency scope

Do not cut agency hours because the handover folder looks complete. Cut scope only after your own team proves it can run the work alone, on a normal week, with no rescue messages and no hidden approvals.

A simple test works better than a status meeting. Ask your team to ship one small, low-risk change from start to finish. That means code, review, deployment, rollback plan, and post-release checks. If they need the agency to unlock a repo, approve a build, find a password, or explain a missing step, you are not ready.

Use a short checklist before you change contracts:

• Your team can ship a release without asking the agency for access, approval, or missing context.
• One company-owned admin account can reach every system that matters, including repos, CI/CD, hosting, domains, app stores, and monitoring.
• Your team can rotate secrets today and knows what breaks, what restarts, and who checks the result.
• Someone can roll back the last release in less than an hour using written steps.
• A new engineer can follow the runbook and complete a release without live help from the agency.

That last test is the one most teams skip. It exposes vague documentation fast. If the runbook says something broad like "deploy from CI" or "check the logs," it is not ready.

Using AI after control is back

After you take back the repos, release access, and operating notes, resist the urge to move everything at once. Pick one product area with clear boundaries, such as bug fixes in a customer dashboard or routine changes to internal admin tools. A narrow start gives your team room to learn without putting the whole product at risk.

AI works best after control is already in your hands. Use it for first drafts of tickets, test cases, release notes, and routine documentation. It can also help developers understand older code, suggest refactors, and fill gaps in runbooks. That saves time, but it should not make final decisions about production.

Keep approval with people for anything that can affect users, billing, data, or uptime. If a release changes live systems, a human should still review the diff, approve the deployment, and confirm the rollback plan. Small teams often skip this when they feel pressure to cut agency hours quickly. Usually, that creates more work a week later.

A simple setup is enough at first: one in-house owner for a single product area, AI support for drafts and routine tasks, one reviewer with release authority, a rollback note for every production change, and a short weekly check on open access gaps and missing runbooks.

Before you reduce agency scope, an outside review can help spot what is still missing. A Fractional CTO can usually find weak points around repo ownership, release rights, environment access, and the runbooks your team will actually use. That kind of review is often cheaper than cleaning up one bad handover.

If you want that sort of practical check, Oleg Sotnikov at oleg.is works with startups and small teams on Fractional CTO support, infrastructure, and AI-assisted development workflows. The useful part is not theory - it is making sure your team can actually ship, recover, and keep control after the handover.