You build until the thing stays on. You detach when you have someone who can hold it, not when the call is tired. At Snowinch handoff is a possible outcome, not a day-one slide about "autonomy".
The founder arrives without a product team. They need an owner, infra, a live that holds. Then, at some point, they hire. Or promote. Or find a CTO who does not want to inherit a mystery. That is the moment you either do a handover, or you become a forever vendor pretending to be in-house.
When staying makes sense
Staying makes sense until live has an owner on your side. Repo, on-call, who rotates a key: if those answers are us, and you do not yet have anyone to take them, vanishing is abandonment. We say so. We stay on the perimeter, or we widen only if the signal asks for it.
Staying also makes sense when the team exists but is new to the system. A month of real pairing (not a PDF) is work. It is not "support on tap" dressed as ownership.
We do not stay out of habit. If the product is on, the team governs it, and the weekly call has become a recap, we are occupying a chair. We detach.
When to leave (and what must be there)
Leaving makes sense when there is a person on your side who can break and fix without writing to us as the first reflex. Not "they read the README". They have shipped a deploy, they have seen a dead job, they know where the secrets sit.
What must be documented, in concrete terms. How you bring the environment up. How you recognise it is broken (not "look at the dashboards": which signal, which threshold, who gets woken). Where the keys are and how you rotate them. Which integrations lie, and in which field. What is out of scope, so the new team does not rebuild the marketplace "because it was in the old deck".
Without that, handoff is a folder. The folder does not answer at two in the morning.
I would rather delay the cut by a few weeks and get the team’s hands on the ugly piece than deliver a "clean" system nobody has touched. The cost is that we look slow to "close the contract". I take that. The alternative is a polite goodbye and an incident the first time a vendor renames a field.
There is a pattern we have seen (no numbers hung on the wall): hours that become collaboration on a whole platform, then a cut when the in-house team is actually there. It works if the cut is a project, not a "you will be fine now". If you treat it as an extra, you will be back in the chat on the first error, angry as if we were still the owners.
An aside: I still have a handoff where the "document" was a one-hour recording, with no list of secrets. The new team played it at 1.5x. The keys were still in a chat. We did the handover again. The recording, alone, was an alibi.
What we do not fake-document
We do not invent a time-to-autonomy. There is no "in N weeks you are independent" that holds across different products. There is: you can deploy, you can revoke, you know where the copies are, you know what is not in scope. When those four are true, you can sign the cut. Before that, no.
It is not a kit. It is not a playbook for sale. On services the build includes the fact that, if you bring it in-house, the product has to be able to stay with you. Same reason few projects and one owner are not a poetics: someone has to be able to pass the ball, not scatter it.
The bridge to validating and then having to hold live is the same object. If you detach on a prototype, you did not hand off. You interrupted a rehearsal.
If you want a forever vendor and no team, say so: we stay, with a perimeter. If you want the cut on day one, with nobody in-house, this is the wrong call. The middle (signal, live, then team) is a contact conversation.
