What Happens to Your Codebase When the Agency Relationship Ends

The agency has delivered. The product is live. You’ve signed off on the final invoice, shaken hands (or sent a warm Slack message), and now the codebase is yours. Except – is it really? Because “ownership” in software is not a binary thing. You can hold the keys to a repository and still be practically locked out of your own product. We see this constantly, and it almost always comes down to the same handful of gaps that nobody thought to close before the engagement wrapped up.

This isn’t about bad agencies acting in bad faith. It’s about the natural incentive mismatch between a team that’s paid to build and ship, and a founder who needs to operate and evolve the thing for the next five years. The agency’s job ends at delivery. Your problems start there.

What “Handover” Usually Means Versus What It Should Mean

Most handovers go like this: the agency transfers the GitHub repo, hands over environment credentials in a shared doc, maybe records a Loom walkthrough of the admin panel, and calls it done. If you’re lucky, there’s a README that was last updated three sprints ago.

That’s not a handover. That’s a file transfer.

A real handover means your next developer – whether that’s an internal hire, a fractional CTO, or a different agency – can pick up the codebase cold and understand it without a two-week archaeology project. It means your infrastructure is in your accounts, not an agency-owned AWS org. It means your secrets are rotated, your CI/CD pipeline is documented, and you know which third-party services are billed to whose credit card.

The gap between “file transfer” and “real handover” is where most post-agency horror stories live.

The Infrastructure Ownership Problem Nobody Warns You About

This one catches founders off guard more than anything else. The agency set up your cloud infrastructure – sensibly, quickly – under their own AWS or GCP organisation. Or they used a shared Vercel account. Or the domain is sitting in their Cloudflare. It made sense at the time. Now you’re trying to onboard a new developer, or move to a different host, or simply understand your own monthly cloud costs, and you realise you don’t actually control the environment your product runs in.

We’ve seen situations where a founder couldn’t even get a straight answer on what services were running, let alone how much they cost, because everything was nested inside the agency’s billing account.

The fix is straightforward but has to happen before the engagement closes:

• Every cloud account (AWS, GCP, Azure, Vercel, Netlify, whatever) should be created in your name, on your credit card, from day one – or transferred before final sign-off.
• The agency should have access granted to them, not the other way around. You invite them in; they don’t own the house.
• Domain registrars, DNS providers, and SSL certificates all need to be in accounts you control.
• Any managed databases – RDS, PlanetScale, Supabase – should sit under your login.

If you’re mid-engagement and this isn’t the case yet, raise it now. A decent agency will sort it out in an afternoon. If they push back, that tells you something.

Secrets, Credentials, and the Rotating Problem

Here’s a scenario that plays out more often than it should: the engagement ends, the codebase is transferred, and six months later you realise the API keys and database passwords baked into your environment variables have never been rotated. They were set up at the start of the build, shared between the agency’s team and yours, and nobody changed them when the relationship ended.

That means former contractors – who may have moved on to build something competitive, or just left the industry entirely – still technically have access to credentials that could affect your production environment. Most of them would never use it. But “most of them” isn’t a security posture.

Before any engagement closes, you should:

1. Audit every secret in your environment – database URLs, third-party API keys, Stripe webhooks, Twilio, SendGrid, whatever your stack touches.
2. Rotate everything. Yes, all of it. Yes, before you go live with a new team.
3. Move secrets into a proper secrets manager (AWS Secrets Manager, Doppler, 1Password Secrets Automation) if they’re not already there.
4. Remove all individual contractor and agency-team access from your accounts – GitHub, cloud, Slack, everything.

This sounds like a lot of admin. It takes a few hours, not days. The alternative is discovering your Stripe keys were compromised eight months after the fact.

Documentation: The Thing That Feels Optional Until It Isn’t

Documentation is the part of a software project that almost everyone agrees is important and almost nobody prioritises. Agencies are not incentivised to write it – it takes time and doesn’t ship features. Founders often don’t push for it because it feels abstract when you’re focused on the product.

Then you hire your first developer and they spend two weeks figuring out why the background job queue is configured the way it is, or why a particular API integration has a 30-second retry delay, or what the naming convention in the database actually means. That’s expensive, and it’s avoidable.

The minimum viable documentation you should demand at handover:

• Architecture overview – a single diagram showing how the main components talk to each other. Not a PhD thesis, just enough for a new developer to form a mental model in an hour.
• Local setup guide – step-by-step instructions for getting the dev environment running on a fresh machine. If it doesn’t work, the agency owes you a working version.
• Environment variables reference – what each secret does, where it comes from, and whether it’s environment-specific.
• Known issues and deferred work – what’s been parked deliberately, what’s known to be brittle, what corners were cut under time pressure. Every build has these. You need to know where they are.
• Third-party service list – every external API, SaaS subscription, or managed service the product depends on, with links and billing ownership noted.

If you’re scoping a new build now, put documentation requirements in the contract. Not vaguely – specifically. What documents, what format, delivered by when.

Test Coverage and Deployment: The Invisible Hand-Off Risk

Two more things that matter more than they appear to at sign-off.

First, test coverage. A codebase with no tests is not automatically bad – plenty of MVPs ship without a full test suite and that’s a reasonable call early on. But you need to know where you stand. If the next developer makes a change to the payments flow and there are no tests covering it, they’re flying blind. Ask for a coverage report. Ask specifically about the critical paths – auth, billing, data writes. If coverage is low, that’s fine, just make sure it’s documented as a known risk and ideally prioritised in the next sprint.

Second, the CI/CD pipeline. How does code actually get from a developer’s laptop to production? If the answer is “the agency’s lead engineer runs a deploy script manually,” you have a dependency you may not have realised you have. Your pipeline should be documented, automated, and running in an account you own. Deployments should not require a phone call to someone who no longer works for you.

When we build at Amora, we ship CI/CD from the first sprint – not because it’s elegant, but because it means the handover is clean from day one. The founder can see exactly how the deployment works because it’s been running in front of them the whole time. That’s the way it should work.

How to Run the Handover Process Without Making It Awkward

The best time to define handover requirements is before you sign the contract. The second best time is now.

If you’re in an active engagement, schedule a dedicated handover sprint or at minimum a handover session in the final two weeks. Treat it like a deliverable – because it is. Give the agency a checklist (use the points above as a starting point) and build it into the project timeline. If you’re paying for 28 days of build, the handover work is part of those 28 days, not an afterthought in week five.

If you’re already post-handover and feeling uneasy, the move is a code audit. Get someone independent – a fractional CTO or a senior developer you trust – to spend a day reviewing the repo and the infrastructure. They’ll surface the gaps quickly. It usually costs $1,500-$3,500 AUD for a thorough review, and it’s almost always worth it before you make any significant investment in the next build phase.

The codebase you paid for should actually work for you. If you’re not sure whether yours does, talk to Amora about your build – we do these audits regularly and we’ll tell you straight what we find.

Ownership isn’t just about having the files. It’s about being able to act on them without asking anyone’s permission. That’s the standard worth holding agencies to – including us.