Article
How to hand a project to another team without losing a month
What stalls a handover is almost never the code. It is the accounts nobody recorded ownership of, and the knowledge that lived in one person's head and was never written down.
Handing a project between teams sounds like a technical problem and is almost always a record-keeping one. The code moves in a minute — it is a repository, you copy it. What takes weeks is discovering who owns the cloud account, who has access to the app store, and where the payment provider's key lives.
We are a software house that both receives projects from other teams and hands them over, so we have seen this from both sides. This page is the list of what has to be true for a handover to take days rather than a month, and what to ask for up front so you do not arrive there unprepared.
What actually stalls
In the order it actually happens: account ownership, unwritten knowledge, and environments that cannot be rebuilt. All three are cheap to prevent and expensive to fix afterwards.
- Account ownership — cloud, domain, app store, third-party services, monitoring. Any one registered to an individual rather than the company is a failure point.
- Unwritten knowledge — why something was decided, what was tried and failed, and which edge case sits behind a strange condition in the code.
- Environments — if the system cannot be stood up from scratch by following a document, what you have is not a handover but a reconstruction.
- Undocumented dependencies — environment variables, keys, and scheduled jobs running somewhere nobody remembers.
The handover document
It is short. A thirty-page document will not be read, and a one-page one will not be enough. What works is three to five pages answering the questions an incoming team genuinely asks in the first week.
- How to run it locally, step by step, on a clean machine.
- How to deploy to production, and who approves.
- What runs on a schedule, when, and what happens if it fails.
- The list of accounts and keys, and whose name each is in.
- The three architectural decisions most likely to surprise somebody new, and why they were made.
That last item saves the most time and nobody writes it. An incoming team seeing an odd choice assumes it is a mistake, rewrites it, and finds out two weeks later why it was there. Three paragraphs prevent that.
What to require in the contract up front
The cheap way to make sure a handover works is not to plan it at the end but to require the conditions at the start. Repository read access from day one, explicit ownership of the code and the accounts, and defined exit terms — all set out in what to check in a software house contract.
There is one further clause worth adding that almost never appears: a defined window for questions after delivery. Two weeks in which the outgoing team answers questions is the difference between a handover and archaeology, and it costs very little when agreed in advance rather than negotiated after a separation.
That figure matters here because it sharpens what a bad handover actually costs. A month lost in transition is not only a month of expense — it is a month in which you learned nothing about the market, and at an early stage that is the resource that runs out first.
When to start preparing
The easiest handovers we have seen were not prepared at the end; they were built into the work from day one. Accounts opened in the company's name rather than a person's, a run document written while the environment was being set up, decisions recorded as they were made. Each costs minutes in the moment and hours afterwards.
The simple check is to ask, each quarter, whether a new developer could stand the system up from the document without asking anyone. If the answer is no, the handover is already expensive — you just have not paid for it yet.
What the incoming team should do
Not rewrite in the first week. The temptation is strong, especially when the code is not in a style you are used to, and it is nearly always a mistake: you do not yet know which of the oddities are debt and which are a forgotten requirement.
What is worth doing immediately is standing the system up from scratch by following the document, and correcting the document wherever it turns out to be wrong. That is the only check that genuinely proves the handover completed, and it leaves behind a document that works for the next time.
If you are still at the selection stage rather than the handover stage, it is worth reading software house vs freelancer — the kind of supplier directly affects how much of the knowledge sits with one person.
In short
- What stalls is account ownership, not the code.
- A handover document of three to five pages, not thirty.
- Write down why the three most surprising decisions were made.
- Agree a two-week question window after delivery, up front in the contract.
From our own work
The most worthwhile thing a client can ask for at kickoff is a written list of accounts and assets and whose name each is in — that is what stalled the handovers we have seen, not the code.
On projects we received from other teams, the check that exposed most of the gaps was standing the system up from scratch by following the document rather than reading the code.
Recurring questions
How long should a clean handover take?
Between a few days and two weeks for a reasonably sized system, assuming accounts are registered correctly and a run document exists. What stretches it to a month or more is almost always account ownership that has to be chased, not the volume of code. A large project with orderly records transfers faster than a small one without them.
What if the outgoing supplier will not cooperate?
This is where the contract's exit terms matter, which is why they are worth reading before signing rather than when you need them. With no such clause, what you can still do is secure transfer of account ownership against payment for work performed, and start documenting whatever you do have immediately.
Should you rewrite the code after a handover?
Not in the first weeks. A good deal of what looks like technical debt is a forgotten requirement or a genuine edge case, and rewriting early brings those bugs back to life. The rule we work to is not to touch the structure until the system runs on our side from scratch and a test covers the primary path.
What about code with no documentation at all?
More common than people expect, and not necessarily a disaster. The fast route is not to read everything but to run the system, walk the primary paths as a user, and document as you go. Documentation written from use is more accurate than documentation written from reading code, and it also finishes sooner.
Sources
- The top reasons startups fail — CB Insights (2026-08-10)
Keep reading
Answer
How to choose a software house — five questions that filter fast
A portfolio shows what came out, not how it was made. Five questions about decisions, people and the contract filter suppliers faster than any introductory meeting, and all fit in one call.
5 min read ·
Answer
How much does app development cost — and why nobody can answer without asking
There is no price for an app, only a price for a scope. This page does not invent a range; it teaches you to read a quote: what raises cost, what lowers it, and where the gap between two quotes actually hides.
5 min read ·
Answer
Why work with Israeli developers on a startup — and when not to
The clear advantage is early-stage product experience and a direct communication culture that shortens cycles. The clear disadvantage is a materially higher price than offshore, and that is a decision rather than a detail.
5 min read ·