Recover ownership after an agency-built launch: first steps

Why this gets messy fast

An agency-built launch often works fine right up to the day you need control. Then you find out the product is live, but the ownership map is missing.

This usually starts with speed. During launch week, people pick the fastest option, not the cleanest one. An agency project manager opens the cloud account with their work email, a contractor creates the analytics workspace, and someone buys a domain or a plugin on whatever card is handy.

A few months later, those shortcuts turn into risk. Your team may have admin access in one tool but not in the one that actually controls releases. A former contractor may still approve app updates, push changes, or hold the only working login for a build service.

Money gets tangled too. Invoices may hit the agency card, the founder's personal card, or an old company card that accounting already closed. When billing breaks, services can pause with little warning. That is a bad time to learn who really owns the account.

DNS is where small confusion turns into a real outage. I have seen teams know who hosts the app but not who controls the domain records. If nobody can log in to the DNS account, even a simple change like moving email or pointing traffic to a new server can stall for days.

The deeper problem is that access often lives in people's heads, not in a shared record. One developer knows the server, another knows the app store, and the founder assumes the agency put everything under the company name. Sometimes that is true. Often it is only half true.

That is why roadmaps and rewrites can wait. If ownership is unclear, every change carries extra risk, and even a small fix can turn into a long week of chasing passwords, invoices, and approvals.

What you need to control first

If an agency still controls the accounts that keep your product live, your team is exposed. A missed payment, a staff change, or a bad handoff can block releases in a single day.

To recover ownership after an agency-built launch, start with the accounts that can lock you out or hide costs. Roadmaps can wait. Control cannot.

Five items usually matter first:

• Put your company on the main repository admin account. Your team should control user access, branch rules, deploy keys, and tokens. If the agency keeps top-level admin, they still hold the master switch.
• Take over the production cloud owner or root login. Use your company email, turn on MFA, and store backup codes where your team can reach them. A cloud account is not really yours if a former contractor can reset access first.
• Move the domain registrar and DNS to your control. If you do not own those two things, you do not fully control your website, email, or future cutovers.
• Claim admin rights in every analytics workspace and export the data. Product analytics, tag managers, dashboards, and raw event exports should sit with your team. Historical data is easy to lose and hard to rebuild.
• Change the billing contact on every paid service. Cloud, email, support tools, monitoring, ads, and AI APIs should bill your company directly. If charges still route through the agency, you cannot see real operating costs.

This is not paperwork. It is risk control. If your app goes down on a Sunday, your team needs the power to log in, pay the bill, update DNS, check analytics, and ship a fix without asking anyone for permission.

A simple rule helps: if an account can stop revenue, block support, or hide data, your company should own it now.

Start with one access list

Most takeovers get messy because nobody has one full view of the accounts behind the product. Before you ask for fixes, features, or a rewrite, make one plain sheet that shows every service the agency used.

Start wide. Add code hosting, cloud, domains, email, analytics, support, design files, app stores, payment tools, and anything used for releases or alerts. If you are trying to recover ownership after an agency-built launch, this sheet becomes your control panel.

A simple set of columns is enough:

• Tool or service name
• What it is used for
• Owner email on the account
• Who has admin, editor, and viewer access
• Renewal date, payment card, and latest invoice

The owner email matters more than many founders expect. If the AWS account, domain registrar, or analytics property sits under a developer's personal Gmail, you do not really control it yet. Mark those rows clearly so your team can move them first.

Permissions need detail. "Agency has access" is too vague. Write the actual names and roles, because one admin can lock everyone else out, while a viewer can do almost nothing.

Billing details tell you what can break next. Add renewal dates, the card on file, and the most recent invoice you can find. This often shows hidden services the agency forgot to mention, like a CI runner, a monitoring tool, or an old plugin that still charges every month.

Keep the sheet live while the handover happens. When your team changes an owner email or removes an admin, update it the same day. A good access list is not busywork. It is the fastest way to see what you own, what you only use, and what could disappear if the agency walks away.

Secure code and releases

Your code host tells you who actually owns the product. If the agency still controls the top account in GitHub, GitLab, or Bitbucket, your team does not control releases yet.

Move ownership to a company account first, then give admin rights to one or two people on your side. Avoid shared logins. Shared logins feel quick, but they make audits, offboarding, and recovery harder.

Check branch rules next. See who can merge into the main branch, who can create tags, and who can push straight to production without review. If a former contractor can still merge or trigger a deploy, fix that before you discuss new features.

A short review usually catches the risky parts:

• company account owns the repo or organization
• your team controls merge rights for the main branch
• CI/CD tokens and build tokens are visible to your admins
• old SSH keys and deploy keys are removed or rotated
• release tags match what is running in production

Secrets need special care because they often stay hidden after a handover. Open the deployment settings and check environment variables, SSH keys, package registry tokens, signing keys, and any build secrets stored in the pipeline. If agency staff ever had access, rotate them. That takes less time than cleaning up after an unwanted deploy.

Then do one very small release yourself. Change a footer line, a hidden admin label, or a non-critical text string. Build it, deploy it, and confirm your team can roll it back. On takeover projects, this simple test tells you more than a week of meetings.

Save a clean copy of the current production release before anything changes. Keep the commit SHA, release tag, build artifact or container image, and a short note about which config version it used. If the next step breaks the pipeline, you still have a known-good version to return to.

Move cloud, domains, and billing to your team

If the agency still owns the cloud account, domain registrar, or payment profile, you do not fully own the product. One missed invoice or one bad handoff can stop releases, break DNS, or lock your team out when something goes wrong.

Start with the cloud account. Put the main owner and billing owner under a company email that founders or internal staff control. Do not leave root access tied to an agency inbox, a freelancer, or a former employee.

Then check domains and DNS. Your team should control the registrar login, DNS records, renewal settings, and transfer lock. If the agency keeps DNS in a separate service, move that too, or you still need them every time you change a record.

Billing needs the same cleanup. Update billing contacts, switch payment cards, and make sure invoices show your company details. Before you change too much, download recent invoices and receipts so your finance records stay complete.

A safe order looks like this:

• Add your company owners and billing contacts first
• Switch the payment method to a company card
• Confirm the next charge or renewal can go through
• Download recent invoices and account history
• Remove old cards after the new payment method works

Teams often rush the last step and create a mess. If you remove the agency card before the new one works, a failed cloud bill or domain renewal can cause downtime for a very boring reason.

A simple rule helps here: ownership first, cleanup second. Get control under your company, test that payments work, save the billing history, and only then remove the agency from the account.

Check analytics, data, and support tools

A product can stay online while your visibility quietly breaks. Before you discuss features or rewrites, open every analytics tool and test live events. Create one real visit, one signup, and one purchase or demo request if that flow exists. If the event count does not move, your reports are already wrong.

Then check paid acquisition. Open ad accounts, pixels, SDK settings, and conversion goals. Make sure your team owns the account, not the agency's business manager or a contractor's login. A common problem is simple: ads still run, but conversions land in someone else's account, so you cannot trust CAC or know which campaign works.

Support data needs the same care. Export customer lists, lead lists, support tickets, refund records, and chat history while access still works. Save raw exports in a company-controlled folder, then note where each system stores the live data. If a customer asks for help tomorrow, your team should not depend on an agency inbox to answer.

Check permissions with extra care. Confirm who can:

• read user profiles and order history
• issue refunds or credits
• view tickets and chat transcripts
• export personal data
• change admin roles or security settings

One small startup mistake causes weeks of pain: the agency sets up support, analytics, and billing with personal email addresses. The founder sees dashboards, assumes ownership is fine, and finds the gap only after a login lockout or a failed refund request.

Recovery access matters just as much as daily access. Backup codes, recovery emails, SMS numbers, and 2FA apps must belong to your team. If account recovery still goes to a former contractor's phone or inbox, you do not control that system yet.

Use this handover order

Take over the accounts that can lock you out first. If you do it in the wrong sequence, the agency can still reset passwords, block releases, or leave you with bills you cannot control.

To recover ownership after an agency-built launch, move in a strict order. That keeps the product live while your team takes over the parts that matter most.

1. Start with email, domain, and identity accounts. If the agency controls your main inbox, DNS, Google Workspace, Microsoft 365, or single sign-on, they can often reset access everywhere else.
2. Take code and deployment access next. Get the source repository, branch rules, CI/CD, app store access, hosting dashboards, and release credentials under your team account.
3. Move cloud and storage after that. Transfer AWS, Google Cloud, servers, buckets, databases, backups, and secret managers once your team can deploy and verify changes.
4. Switch billing owners before the next renewal. Payment methods, invoices, tax details, and subscription contacts should point to your company, not the agency or a freelancer.
5. Ask for documents and a live walkthrough at the end. Written notes help, but a real handover call usually reveals the small things that break later, like cron jobs, hidden admin users, or one-off scripts.

This order works because each step makes the next one safer. If you move cloud first but the agency still owns the domain or identity account, they can still lock you out. If you switch billing too late, you may pay rush fees, lose service, or miss a renewal notice.

Keep one person on your side in charge of the full checklist. They should confirm each transfer, test access, and record who owns what before any roadmap talk or rewrite starts.

Mistakes that slow the takeover

The fastest way to lose time is to argue about a rewrite before your team owns production. If the agency still controls deploys, cloud billing, domains, or analytics, every product decision rests on shaky ground. To recover ownership after an agency-built launch, take control of access first and leave architecture debates for later.

Teams also create trouble when they cut off the agency too early. Keep access in place until your team copies records, exports settings, saves invoices, and writes down how releases work. If you delete accounts first, you can lose build history, DNS records, ad account IDs, or support threads that explain old customer issues.

Another slow, painful mistake is changing too many systems on one day. A founder moves cloud billing, rotates secrets, switches analytics, updates release pipelines, and changes domain settings before lunch. By evening, login fails and nobody knows which change caused it. Move one area at a time and confirm it works before you touch the next one.

Support tools and app store accounts often slip through the cracks. A startup may regain GitHub and AWS access but still miss urgent tickets because the agency owns the main inbox. Mobile teams hit the same wall when the Apple or Google account still belongs to the vendor.

Do not accept screenshots as proof that everything is under control. Your team needs to log in, not just see a picture of a dashboard.

A quick check should include:

• opening the production repo with admin access
• viewing cloud billing and active subscriptions
• logging into analytics and confirming live data
• sending a test reply from the support inbox
• checking who can ship an app store release

If your team cannot do those actions itself, the takeover is not done.

A simple startup example

Lena runs a small SaaS company. She paid an agency a fixed fee to launch the first version of her app, and they got it live fast enough to start taking customers.

Two months later, she wants to fix signup drop-off and add one new feature. That sounds simple until she asks for access. The agency still controls the cloud account, the DNS settings, and the release pipeline. If the app goes down, her team cannot even restart a service without asking someone outside the company.

The mess gets worse when she checks the rest of the stack. Analytics still collects data, but Lena cannot edit conversion goals, create clean exports, or confirm which events the product team should trust. Support emails still land in the inbox of a former agency project manager, so customer issues reach her late.

At that point, Lena stops talking about redesigns and new features. She decides to recover ownership after an agency-built launch before she discusses any roadmap.

She asks for four things first:

• admin access to the code repo and release tools
• transfer of cloud, DNS, and billing to company-owned accounts
• admin rights for analytics, exports, and event settings
• control of support inboxes, forms, and customer replies

That choice saves her time almost at once. She finds an old DNS record nobody documented, a billing card tied to the agency owner, and a support rule that silently forwarded urgent tickets to an address nobody checked.

Only after her team controls those accounts does she schedule product work. That order may feel slow for a week, but it prevents a bigger delay later. A roadmap discussion means very little when someone else still holds the keys.

Quick checks before roadmap talks

If you're trying to recover ownership after an agency-built launch, pause feature planning for a day and verify basic control first. A roadmap is guesswork if someone else still owns the logins, the release process, or the bills.

Do not rely on screenshots or promises. Open each system, sign in, and test one real action with your team.

Check these five things before you discuss new work:

• Your team can log in to every paid tool that keeps the product running, measured, or supported.
• Your company controls the main email accounts used for admin access, password resets, invoices, and alerts.
• Someone on your team can deploy a change, roll it back, and read logs without asking the agency for help.
• You can see product usage, revenue, and support history in the tools that matter.
• Every monthly charge goes to a company card, company bank account, or company-owned billing profile.

One missed item can block everything. A founder might have the source code but still get stuck because the agency owns the release pipeline. Or the team may control the cloud account but miss the billing login for analytics, so a failed payment quietly cuts off reporting.

A simple rule helps: if a vendor sends alerts, renewal notices, receipts, or password resets, those messages must go to your company. If the agency still receives them, you do not fully control that part of the business.

If an outside CTO advisor reviews the handover, ask for a live check, not a document review. Ten minutes of real logins, a test deploy, and one billing audit will tell you more than a long roadmap meeting.

What to do next

Set a firm two-week deadline and treat the handover like a small project with an owner, a checklist, and daily follow-up. If you want to recover ownership after an agency-built launch, an open-ended transfer usually turns into delays, missing passwords, and vague promises to "send that later."

Keep the last steps practical. You do not need perfect documentation yet. You need enough control to run the product without asking the agency for routine help.

Write short notes for the few things your team will touch first:

• how releases happen and who can approve them
• where billing lives, who pays, and when renewals hit
• how support requests come in and who answers them
• what to do if the site, app, or login breaks

These notes can be plain and brief. A one-page release note is better than a polished wiki nobody finishes.

At the same time, cut access down to the minimum the agency still needs. If they are fixing a final bug, keep that access narrow and time-limited. Remove old admin rights, shared logins, and payment access your team does not want them to keep. This is where many startups slip. They think the handover is done, but the agency still controls one release account, one domain login, or one support inbox.

Only after that should you review the roadmap, tech debt, and staffing. Until ownership is clear, rewrite ideas and new hiring plans are mostly guesswork.

If you want a second pair of eyes before making bigger changes, a fractional CTO like Oleg Sotnikov can review access gaps, release risk, cloud and billing ownership, and the next technical steps. That kind of review is often much cheaper than cleaning up one more handover mistake a month later.