Taking Back Your Product: The Handover Playbook

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A Dubai-based Series A SaaS founder who shipped their MVP with an external studio and has just hired their first two in-house engineers — and needs the product genuinely running in their team's hands, not still dependent on the vendor, within 60 days

A real handover is complete when one of your own engineers has pushed a non-trivial change to production, rotated every credential, and resolved an on-call incident without the vendor on the call. If any of those three things has not happened yet, you do not own your product — you are renting it with an option to buy, and the vendor still holds the keys. This playbook is the sequence a founder runs over roughly 60 days to close that gap.

The context matters. You are not alone in this: 70% of companies have repatriated some previously outsourced work in the last five years, and the top two reasons are tighter quality control (68%) and rebuilding internal expertise (64%) — not cost. The failure mode is almost always the same. The vendor hands over a repository and a walkthrough video. The founder signs off. Three weeks later the first production incident hits, the in-house team cannot find the Stripe webhook secret, and the vendor's senior engineer — the one who actually built the thing — has already rolled off to a new client, or left the vendor entirely. Outsourced teams carry 25–30% annual turnover, so the person who holds the tribal knowledge is often already gone before you start.

The non-obvious point: a handover without a signed runbook acceptance and at least one full deploy-to-production cycle completed by your engineer — not the vendor's — is not a handover. It is an IOU the vendor can honour at their convenience, usually timed to your next crisis. Everything below is designed to collect on that IOU before the crisis arrives.

Step 1 — Write the acceptance criteria before you schedule the handover meeting

Most founders treat the handover as a meeting. It is a deliverable, and deliverables need acceptance criteria written down before work starts. Do this in week one, before your in-house engineers even touch the codebase.

At minimum, the acceptance criteria should cover: a complete inventory of every third-party service and who owns the account, a runbook that your engineer can follow to deploy to production from a clean laptop, a documented local development setup that works in under a day, an architecture decision record covering the five or six choices that are not obvious from reading the code, and a list of known issues and tech debt the vendor is aware of but did not fix.

Anti-pattern: accepting "we'll document as we go." Documentation written during handover is the only documentation you will ever get. If it is not in the acceptance criteria, it will not exist.

You'll know this step is done when: the vendor has countersigned the acceptance criteria and agreed that final payment (or the retainer wind-down) is contingent on meeting them. Not when they have "reviewed" it.

Step 2 — Do a credentials and access audit in week one, not week six

This is the single most skipped step and the one that creates the worst lock-in. In your first week with the new engineers, build a spreadsheet with one row per external service. Columns: service name, account owner (email), billing owner, admin user list, where the API keys currently live, where they should live, and rotation status.

Walk the codebase and grep for every environment variable, every API key, every webhook URL. For each one, find the corresponding account. You will almost certainly discover: services billed to the vendor's credit card, admin accounts in the name of a developer who no longer works at the vendor, shared logins, API keys hardcoded in old config files, and at least one service nobody can identify the purpose of.

Then rotate everything. Every key, every secret, every webhook signing secret. If a key cannot be rotated without breaking production, that is a Priority 1 ticket, not a footnote. The act of rotation is also the test — it proves your engineer understands where the secret is used and can redeploy safely.

Anti-pattern: trusting the vendor's list of "all the services we use." They will forget two or three. The codebase is the source of truth, not the memory of a project manager who has moved on.

You'll know this step is done when: every external service is billed to your company, every admin account is held by your team, and every production secret has been rotated by your engineer at least once.

Step 3 — Force the first production deploy through your engineer's laptop

This is the checkpoint most handovers fail. Schedule a specific, low-risk change — a copy tweak, a feature flag, a config change — and require that your in-house engineer be the one who merges, deploys, and verifies in production. The vendor can be on a call. They cannot touch the keyboard.

You are testing three things: whether the local dev setup actually works, whether the CI/CD pipeline is accessible to your team (not just to the vendor's accounts), and whether the engineer knows what to do if the deploy fails. If any of those three breaks, you have found exactly what the handover documentation missed.

Repeat this three times within the first month, with progressively less vendor involvement. First deploy: vendor on the call. Second: vendor on Slack. Third: vendor unavailable (schedule it when they are offline).

Anti-pattern: "The vendor will deploy this last batch of fixes before we take over." Every deploy the vendor does on your behalf after the handover starts is a deploy your team did not learn from. The point is not to get the change shipped; the point is to prove the pipeline works for you.

You'll know this step is done when: your engineer has deployed to production without the vendor involved, and a deploy has failed and your engineer has rolled it back without the vendor involved. The second part matters more than the first.

Step 4 — Run the runbook, do not read it

The runbook is the document that tells on-call what to do when things break. Most vendor-produced runbooks are untested fiction. The way you validate one is a tabletop exercise: pick five realistic incident scenarios and have your engineer work through the runbook as if the incident is happening live.

Suggested scenarios: payment webhook stops firing, the database is at 95% CPU, a third-party API returns 500s for an hour, a customer reports they cannot log in, the primary application region goes down. For each one, your engineer opens the runbook and attempts to execute it. The vendor observes and notes every step where the runbook is wrong, incomplete, or references a dashboard the engineer cannot access.

Research on outsourced software maintenance transitions found application-specific knowledge is the hardest domain to transfer — harder than generic technical skill. Runbooks are where that knowledge either gets written down or gets lost. A documented enterprise case spent over 600 person-hours recreating integration documentation after a vendor team was replaced. That is the cost of skipping this step.

Anti-pattern: accepting a runbook that says things like "restart the service" without naming the exact command, the exact environment, and the exact confirmation that it worked. Vague runbooks are worse than no runbook — they create false confidence.

You'll know this step is done when: your engineer has executed all five scenarios end-to-end and signed off on the runbook as accurate. Their signature, not the vendor's.

Step 5 — Capture the architecture decisions, not just the architecture

An architecture diagram tells you what exists. An architecture decision record (ADR) tells you why it exists — and why the alternatives were rejected. The second is far more valuable when your engineer is deciding whether to extend a pattern or replace it.

Sit the vendor's tech lead down for a half-day session and walk through the five or six decisions that are not obvious from reading the code. Why this database and not another. Why this queue. Why this auth approach. Why the webhook handler is structured the way it is. Why this feature was built custom instead of using a vendor library. Record the session. Write it up as ADRs — one page each, in the repository.

This is also the moment to ask the uncomfortable question: "What would you rebuild differently if you were starting now?" Vendors will answer this honestly at handover in a way they would never answer during the engagement. 61% of developers already spend over 30 minutes a day searching for answers; your new hires will spend much more than that if they have to reverse-engineer intent from code.

Anti-pattern: treating the architecture diagram as the deliverable. Diagrams age badly and tell you nothing about the tradeoffs. ADRs age well because they are explicitly about a moment in time.

You'll know this step is done when: your engineer can explain, in their own words, why each major architectural choice was made and what the alternative would have cost.

Step 6 — Negotiate a tapering support window, not a cliff

Do not end the vendor relationship at the handover date. Structure a 30-to-60-day tapering support window: full responsiveness for two weeks, then business-hours Slack for two weeks, then a monthly retainer of a few hours for questions. This costs modestly more than a hard cutover and dramatically reduces your risk.

The tapering window is where the last 10% of tribal knowledge transfers — the stuff that only surfaces when your engineer hits a specific weird edge case at 3am. Budget for it. Also use it as leverage: the final payment or the final retainer month is released when the acceptance criteria from Step 1 are met, not when the calendar says the engagement is over.

Anti-pattern: a hard end-date with no support tail. You will need the vendor at least twice in the first 60 days, and if there is no contractual basis for that, each call becomes a negotiation.

You'll know this step is done when: your in-house team has gone a full two-week period without contacting the vendor, and the vendor's final invoice has been released against signed acceptance of all criteria.

How long and how much this takes

The handover itself is typically a 30-to-60-day exercise running in parallel with your in-house team's normal onboarding. The main drivers of the timeline are: how many third-party integrations exist (each one is a credential audit, an account transfer, and a runbook entry), whether the codebase has a working local dev setup today or needs one built, how much undocumented infrastructure lives in the vendor's accounts (AWS, Vercel, GitHub Actions) versus yours, and whether your incoming engineers have shipped on a similar stack before.

The cost is mostly the opportunity cost of your in-house engineers spending 30–50% of their first two months on handover work instead of new features, plus the tapering vendor retainer. The tradeoff is real: you are deliberately slowing feature velocity for two months to buy years of independence. Founders who skip this trade almost always pay for it later, usually at 10x the cost, when a production incident lands during a vendor's holiday break.

The specifics that turn this range into a real plan: the number of external services and integrations in your stack, the current state of your deployment pipeline, and the seniority of your first two in-house hires. Those three variables determine almost everything.

How CodeNicely can help

We have been on both sides of this. We build MVPs for founders, and we also take over products from other studios when founders decide to bring development in-house or switch partners. The GimBooks engagement is the closest analogue to a Dubai Series A founder's situation: a YC-backed fintech where we inherited a product mid-flight, ran exactly the kind of credentials-and-ADR audit described above, and had their in-house team shipping independently within weeks — with full IP ownership documented and no retainer lock-in. When we hand over, we write the runbook to be executed by the incoming engineer, not read by them, and we structure the tapering support window into the contract from day one.

If you are a UAE-based founder running this playbook against your current vendor and want a second pair of eyes on the acceptance criteria — or a neutral party to run the runbook tabletop — our Dubai team does this as a scoped engagement. No pitch to replace your vendor; just the audit.

Frequently Asked Questions

How long does a software handover from an outsourced team actually take?

Typically 30 to 60 days running alongside your in-house team's onboarding. The drivers are the number of third-party integrations, whether a working local dev setup exists, how much infrastructure lives in vendor-owned accounts, and the seniority of your incoming engineers. To turn that range into a real timeline, you need an inventory of external services and a look at the current deployment pipeline — that is a one-week discovery, not a guess.

What should be in a dev partner handover checklist?

At minimum: an inventory of every third-party service with billing and admin ownership transferred to you, every production secret rotated by your engineer, a runbook tested against five real incident scenarios, architecture decision records for the non-obvious choices, a local dev setup that works from a clean laptop in under a day, and at least three production deploys executed by your in-house engineer without vendor hands on the keyboard.

Who owns the code and IP after an outsourced MVP?

It depends entirely on your contract. Reputable studios assign all IP to you on final payment with no retention. Others retain rights to "reusable components" that can be ambiguous enough to matter later. Have a lawyer review your original MSA and SOW before the handover — this is not advice we or any studio should give you second-hand.

What is the biggest risk in transitioning from outsourced to in-house development?

Losing application-specific knowledge — the why behind decisions, not the what. Research on outsourcing transitions identifies this as the hardest knowledge domain to transfer. The vendor's senior engineer leaves, and with them goes the reason a certain integration is structured a certain way. Architecture decision records written during handover are the only reliable defence.

Should we keep the vendor on a retainer after handover?Yes, for 30 to 60 days on a tapering basis. A hard cliff almost always produces a scramble in week three when an edge case surfaces. A modest retainer with explicit response-time expectations costs far less than the equivalent emergency call-out, and it gives you leverage to hold the final payment against signed acceptance of the handover criteria.