Code Handover Done Right: Owning What You Paid For

You’ve spent six figures on a new SaaS product or platform. The agency demo’d it last week. It works. Now they hand you a folder of files, a GitHub repo URL, and a wave goodbye. Six months later, you need a small fix. The original team isn’t available. You discover the codebase has zero documentation. Nobody knows why that payment module is structured that way. You’re stuck.

This happens constantly. Not because agencies are malicious-most aren’t-but because “handover” is often treated as a checkbox, not a foundational principle. You paid for software. You deserve to actually own it.

Why Code Ownership Matters More Than You Think

When you commission software, you’re not just buying a product. You’re buying the ability to maintain, extend, and evolve it independently. If you can’t do that, you’ve rented a black box, not bought an asset.

The practical cost of poor handover shows up fast:

• You can’t hire junior developers to maintain it. Without documentation, onboarding a new engineer costs 3-4 weeks instead of 5 days.
• Security patches take forever. A vulnerability in a dependency takes you weeks to assess because you don’t understand the architecture.
• You’re locked to one person or vendor. The original builder is now your bottleneck, which they know, which changes the pricing conversation.
• You can’t confidently pitch investors. Due diligence on custom software always includes a code review. Unexplained architecture, missing tests, and no docs will kill a deal before the technical founders even argue about it.

A proper handover costs the agency maybe 5-10% extra time during the build. The ROI to you is permanent independence.

What a Real Handover Includes

Not all documentation is equal. Boilerplate README files don’t count. Here’s what you should actually receive:

1. Architecture document (2-5 pages). High-level explanation: what services talk to what, where data flows, why certain choices were made. Not code comments. Actual narrative explaining intent. “We used PostgreSQL for transactional data and Redis for session caching because the payment flow needs consistent ACID guarantees.” Not just “database setup instructions.”
2. Deployment runbook. Step-by-step: how to deploy to production, what environment variables exist, what they do, how to roll back, what breaks if you misconfigure something. A junior dev should be able to deploy without Slack messages to the original builder.
3. Testing documentation. Which tests matter. How to run them. Which ones catch real bugs versus which are just coverage metrics. “Run npm test -- --coverage before merging; if coverage drops below 70% on new code, the PR fails.”
4. Known limitations and tech debt. Every codebase has corners cut. The builder should list them: “We’re not caching the user dashboard query yet (rough cost: 200ms per page load). If you hit 10k concurrent users, this becomes a bottleneck.” This isn’t admitting failure; it’s being honest about trade-offs.
5. Dependency inventory. A simple list: what third-party services does the app rely on? Payment gateway? Email provider? SMS service? What credentials does each need, who has access, how do you rotate keys?
6. Code comments on the tricky bits. Not every line. But the bits that aren’t obvious: complex algorithms, workarounds for library quirks, business logic that seems backwards until you understand the regulatory reason.

Total time to produce this: roughly 8-12 hours for a typical MVP. For a build that took 4 weeks, that’s reasonable.

The Handover Meeting That Actually Works

A two-hour Zoom call doesn’t count. Here’s how to structure it:

Part 1: Architecture walkthrough (45 minutes). The senior dev who built it talks through the system, showing the actual code. Not a slide deck. You’re looking at the real structure, asking “why does it work this way?” The goal is you understand it well enough to explain it to someone else.

Part 2: Running it locally (30 minutes). You follow along on your machine while the builder walks through environment setup, running tests, starting the dev server. Every step should be documented so you can repeat it alone.

Part 3: Common operations (30 minutes). “How do I add a new user role?” “How do I change the payment plan thresholds?” “What happens if the third-party API goes down?” The builder shows you where in the code these things live and how to change them safely.

Part 4: Questions and edge cases (15 minutes). Open floor. This is where you find out about weird behaviour, workarounds, or things that seemed fine during build but might bite you later.

Record it. You won’t remember everything. New team members will want to watch it later.

The Contract and Acceptance Clause That Prevents Arguments

Don’t leave handover to goodwill. Your contract should specify what “complete” means. Example language:

“Delivery is considered complete only when: (1) all code is committed to the agreed-upon repository with full history; (2) the Deployment Runbook, Architecture Document, and Testing Guide have been delivered and reviewed; (3) a handover meeting has occurred; and (4) the client confirms they can deploy to production and perform basic maintenance operations without contractor assistance.”

This isn’t legal posturing. It protects both sides. It forces the agency to actually do the work, and it gives you a clear standard for acceptance. If they push back, that’s a red flag.

Some builders will say “documentation slows us down.” It doesn’t. It prevents late-night debugging calls at 2 a.m. It shifts work from support to prevention. Any agency serious about shipping good software will already do this.

What Happens After Handover

You’ll find bugs. You’ll need small tweaks. The agency should offer a short support window-usually 30 days-where they fix showstopper issues at no extra cost. After that, you’re independent. If you need more help, you hire them, or you hire someone else. You have the choice.

That independence is the point. You own what you paid for.

If you’re building something substantial and want to ensure handover goes properly from day one, it helps to partner with a builder who treats it as fundamental, not optional. When you talk to Amora about your build, we include proper handover in every scope. It’s built into our process, not added on.

The software you commission should work for you, not trap you. Insist on real ownership. The cost is minimal; the payoff is permanent.