The launch email went out. The last person dropped a zip in Slack and disappeared. Who owns the product after launch is the question nobody put in the brief — and the reason so many live products are orphans by Tuesday.
I ask this before I quote, in the same week of scoping as the first user and the cut line. If nobody will own it in month two, I build the first version differently — fewer moving parts, boring hosting, nothing that needs a babysitter. That is also what I own as a full-stack developer: not a repo, production. You can see the shape of that in the work.
What done means after a product launches
Done is not a deploy. Done is a named person who can still open the thing next month: change a line, ship it, see a payment fail, not panic. If that person is you, fine. If that person is me, say so. If that person is nobody, you do not have a product. You have a demo with a domain.
Agencies sell launch as an ending because endings are easy to invoice. The product does not care. Users arrive after the screenshot. Payments fail after the toast. The domain bill arrives in the other person's email. Launch without an owner is how you get the zip file six months later, and a new hire staring at a repo they cannot run.
What I hand over after launch
A handoff is three artefacts, not a feeling. I have taken over enough products where none of these existed — taking over an existing product without a rewrite starts with getting the keys the last person never left. I will not be that last person.
- 01
The keys
Repo, hosting, domain, env vars, analytics, the payment account. If any of those sit in someone else's email, you do not own the product. I do not leave until those are in yours, or in a place you can open without calling me.
- 02
A deploy you can repeat
Not a ritual I perform on my laptop. A path you can run, or I can run, without archaeology. If the last ship was a mystery, that is the first thing I fix before anyone talks about a handoff.
- 03
A one-page note
What can break, where the logs are, what must not be touched on a Friday. A wiki nobody reads is not a handoff. One page you can find is.
If I built it, those three are part of shipping — same as the rest of the build. A zip in Slack is not a deliverable. It is a way to leave.
When I stay after a product launches
Staying is a decision, not a default. It has a shape. If you need me after launch, I want to know which of these it is, before the launch email, not after the first broken Tuesday.
- 01
The first weeks in production
Real users find the edges staging never did. A payment fails. A report is empty. I want those weeks inside the build, not as a surprise invoice the week after the launch email.
- 02
The next milestone that was always real
The admin, the second job, the thing written below the line. That is not aftercare. That is the next piece of the brief, priced as its own piece.
- 03
Fixes, small changes, watching
The product is live and it needs a named person. Not a team. Not 2am. A place to send the thing that broke, and someone who can ship a fix without a kickoff call.
I stay
A named person for Tuesday
First weeks, a later milestone, or ongoing care. Written down. Priced. Not a vibe.
A zip file
A repo you cannot run
Passwords in a thread, a domain in someone else's account, and a hope that nothing breaks.
When you should own the product after launch
I am not trying to rent your product forever. Some endings are clean. These are the honest ones — and the one that looks like an ending and is actually a mess.
- 01
You have someone who can ship a fix
An in-house person, a contractor you already trust. I hand over the keys and the note. If they cannot deploy without me, we are not done — that is still my problem, not a personality clash.
- 02
Nobody is going to own it, on purpose
Then I would have built it that way from the start: fewer moving parts, boring hosting, nothing that needs a babysitter. Telling me that in week one is useful. Telling me in week twelve is how you inherit a machine you cannot touch.
- 03
You were sold a zip file
A repo in Slack, a half-paid invoice, passwords in a thread. That is not a handoff. That is how I end up taking the thing over. If that is what the last person left, start with the keys, not a new brief.
A product with no owner after launch is a demo with a domain.
If you already know who owns Tuesday, put it in the first email. If you don't, that is the brief. The rest of after launch is that sentence from different angles, and most of hiring a developer is whether they will still be in the room when the launch email is forgotten.
