Who Owns the New Product After It Ships

Ownership is four separate questions, not one. Most contracts answer the first and leave the other three implicit, which is why arguments about ownership usually happen after launch, when the answers are expensive to change.

The four are: who owns the code, who owns the infrastructure it runs on, who answers when it breaks at three in the morning, and who decides what gets built next. They can each sit in a different place, and mixing them up is what goes wrong.

Key takeaways

• Four questions, not one: Code, infrastructure, on-call and roadmap are separable.
• Settle them before the first commit: After launch, every answer has a migration attached.
• Code ownership is the easy one: It should be yours from the start.
• On-call is the one people forget: And it is the one that wakes someone up.

Question 1: who owns the code

This should be you, from the first commit, with the repository in your organisation if you want it there. There is no good reason for a supplier to hold the code of a product you paid to have built, and arrangements where the code is released on final payment create a hostage situation at exactly the wrong moment.

Check the intellectual property clause before signing rather than after. In many agreements the code transfers on payment, but "many" is not "all", and the ones that differ rarely advertise it.

Question 2: who owns the infrastructure

Whose cloud account does it run in, and whose name is on the domain, the app store listing, the payment provider account and the monitoring service?

Running in the supplier's account is convenient at the start and a problem at the end, because moving a running system between cloud accounts is real work that nobody budgets for. Running in your own account from day one costs an afternoon of setup and removes the whole category of problem.

The app store developer account is the one to be most careful about. Recovering one from an uncooperative party is slow, and until it is resolved you cannot ship an update to your own users.

Question 3: who is on call

The question that gets skipped. If the new product breaks at three in the morning, who is woken up, what are they expected to do, and what is the agreed response time?

This is worth answering separately from the others because it can legitimately differ. A common and sensible arrangement is that the external team holds on-call while they are building and for an agreed period afterwards, then it transfers on a date. What does not work is leaving it unsaid, because the default is that nobody is on call, which is discovered during the first incident.

If the new product depends on your existing system, also agree what happens when your side is the thing that is down, and who tells whom.

Question 4: who owns the roadmap

Who decides what gets built next, and who can say no.

This should be you, always. An external team can and should advise on sequencing and cost, but a product whose direction is set by its supplier drifts toward what the supplier finds interesting or profitable. Keeping this one internal costs you a few hours a month and it is the difference between commissioning a product and receiving one.

A worked default

For most arrangements, this combination works:

The only row with real negotiation in it is the third and fourth, and the negotiation is about the date rather than the principle.

Handover is a piece of work, not a moment

If any of these transfers at the end, put a date on it and treat it as a deliverable: the codebase, the architecture notes, the runbook, the credentials, and a period of the external team sitting with yours. Two weeks is typical.

Building with handover assumed changes what gets written down, which is why the decision has to be made at the start rather than at the end. We cover the full setup in building a new product without pulling your team off.