What to Do When Your Client Contact Leaves Mid-Project (Keep the Claude Code Build Alive)

The Short Answer

When your main client contact leaves mid-project, move fast. Within a day or two, email your contact (if they are still there) or their manager and ask one question: who owns this project now? Then make sure nothing on the build depends on the departing person's accounts, send the new owner a short brief of where the project stands, and get on a call to walk them through the outcome the build is for. The goal is to turn the new contact into the project's new champion before they decide it is someone else's leftover.

That is the Handover Reset. It works because the biggest danger is not that the new person dislikes the build. It is that nobody owns it, so it drifts, invoices go unapproved, questions go unanswered, and months later someone cancels it because they cannot remember why it exists.

Why a Departure Puts the Build at Risk

Your contact was more than a mailbox. They chose you, argued for the budget, knew why each decision was made, and approved your invoices. When they leave, all of that leaves with them unless you rebuild it. Expect some of these to show up.

• No owner. The project gets passed to someone already busy, who treats it as low priority. Replies slow down and approvals stall.
• Lost context. The new contact does not know the scope, the trade-offs, or the changes you already agreed. They may question work that was approved months ago.
• Locked accounts. Logins, API keys, hosting, domains, or billing set up under the departing person's work email can get switched off when their account is closed, sometimes taking the build down with it.
• Payment gaps. Invoices that went to the old contact sit unread. Nobody is approving them, so nobody is paying them. [How to handle a client who pays late](/blog/how-to-handle-a-client-who-pays-late) covers the follow-up if this happens.
• A fresh look at the budget. A new owner often reviews every outside cost they inherited. A build they do not understand is an easy line to cut.

Run the Handover Reset

Work through these in order. The first two protect the build. The last three protect the relationship.

• Confirm the new owner in writing. Ask your departing contact, or their manager, who now owns the project, who approves the work, and who approves invoices. Get names and emails, and update where you send invoices the same day.
• Secure access. List every account the build touches: hosting, domain, database, code repository, API keys, payment tools, automations. Any that sit under the departing person's email need a new owner on the client side before their account is closed. Claude Code can help you build the list: point it at the project's config files and environment variable names and ask it to list every outside service the build connects to. Check the list yourself, and never paste real keys into a prompt.
• Send a one-page brief. What the build is for, in business terms. What is done, what is in progress, and what is left. Key decisions already made and why. The next milestone and its date. Open questions you need answered. Keep it to one page so it actually gets read.
• Book a short intro call. Not a status meeting - a chance to hear what the new owner cares about. Ask what they were told about the project, what they would need to see to call it a success, and how they like to get updates.
• Re-sell the outcome. Connect the build to what the new owner is measured on. If they care about response times and the build is a support assistant, lead with that. [Prove the ROI of your build](/blog/prove-the-roi-of-your-build) covers how to show the number that matters to them.

Re-Confirm Scope, Timeline, and Payment

After the intro call, send a short written recap: the scope as agreed, the next milestones and dates, how invoices will be approved and paid, and how you will send updates. Ask the new owner to reply confirming it. That reply is your new sign-off, and it stops the 'I never agreed to that' conversation before it starts. Then keep sending a [weekly client update](/blog/weekly-client-update-prevents-fires) to the new owner, so the project stays visible.

If the new owner wants to rethink the project, do not argue for the old plan. Ask what outcome they need now, and propose the smallest version of the build that delivers it. A smaller project the new owner believes in is worth more than a larger one they quietly let die.

Set Up the Next Project So One Exit Cannot Stall It

• Put the agreement in the company's name, not a person's. A [one-page agreement](/blog/one-page-agreement-before-you-build) signed by the business survives any one person leaving.
• Keep every account on a company email or a shared admin account the client controls, never on one employee's personal login.
• Know at least two people on the client side: the day-to-day contact and the person who signs off on budget. Copy the second on milestone updates.
• Write decisions down as you go. A short decision log in the project, which Claude Code can keep updated from your notes, means the next contact can catch up in one read.
• Hand over documentation at every milestone, not just at the end. [How to offboard a Claude Code client](/blog/how-to-offboard-a-claude-code-client) covers what a clean handover includes.