Who owns production after launch
Antonio Chagoury, Founder & CEOOctober 27, 2026
The build shipped on a Thursday. The channel went quiet. At 1:14 a.m. production paged.
Nobody could say who was on call. The deploy notes lived in a thread. The secret the job needed sat in one person's password manager. That person was asleep. They were also no longer on the account.
That is the first night. It is not bad luck. It is what happens when launch is a date, and ownership is a feeling.
I am not writing a checklist of tools. I am writing what I would tell a founder the week the build team moves on. Name the person. Name the backup. Name who can deploy, who can roll back, and where the secrets live. If you cannot say those names out loud, you do not have production. You have a demo that happens to be up.
What owning production means
One named person for every system that is up. That person can deploy it, roll it back, and point at the secret store. A second name sits next to them. If both are out, say that out loud. A system with no owner is not launched.
"The team" is not an owner. A Slack channel is not an owner. The vendor who built it is not an owner once the contract is over, unless the contract still says they pick up the phone.
On-call is a rotation and a phone number, not a hope that someone sees a message. A deploy is a path more than one person can run. Secrets live in a store the on-call account can read. They do not live on a laptop that left with the contractor.
The first night something breaks
The page fires. Then four questions, in this order. If any one of them is a maybe, the night gets long.
Who is the number? One person is awake for this system tonight. Their phone is the page. A backup is named for when they do not answer. If the page goes to a group, and everyone assumes someone else has it, nobody has it.
Can they deploy? The fix is a small change. The path to production is a checklist one person remembers, and that person is the one who left. A deploy you can only run on a happy Thursday is not a deploy. It is a ceremony.
Can they read the secret? The job needs a key. The key is in a personal vault, or in a note, or in an environment only the old laptop had. The on-call account cannot see it. You are now debugging access, not the outage.
Can they roll it back? The last change is the suspect. Rollback is a button, or a written order a second person can follow. If rollback is "whoever remembers," you will ship forward at 3 a.m. and make it worse.
| Question at 1 a.m. | What good looks like | Not good enough |
|---|---|---|
| Who is on call? | One name, a phone, and a backup name. | A channel. "Someone will see it." |
| Who can deploy? | At least two people, on a path you can run on a Tuesday. | The person who built it, if they answer. |
| Where do secrets live? | A store the on-call account can read. A list of who else can. | A laptop, a thread, or one person's vault. |
| How do you undo the last change? | A rollback a second person can run without a meeting. | Memory. A Friday window. Hope. |
A name on every system
Write the list before you call it done. One row per system that is actually in production. Not the diagram. The thing that pages.
| System | Owner | Backup | Where secrets live | Who can deploy |
|---|---|---|---|---|
| The app customers use | A person, not a role title alone | A second person | The store, named | Owner and backup |
| The job that runs at night | The same standard | The same standard | Not a laptop | Not one contractor |
| The vendor you depend on | Someone inside your company | Someone who can open the vendor ticket | Their keys, in your store | You still own the page |
A vendor can run the servers. A vendor cannot be the only name. When their contract ends, or when they are asleep, the page is still yours. The owner inside your company is the person who can revoke them, call them, and keep the system up if they do not come back.
If a row has a blank, that system is not handed off. Finish the row, or say you are keeping the risk.
What the build team owes you before they leave
The last week of a build is the handoff, not a victory lap. I want five things in writing, in a place the next owner can open without asking.
- The owner and the backup, for each system, with the phone the page uses.
- The deploy path, written so a second person can run it. Including how to stop.
- The rollback, tried once while the build team is still in the room.
- The secret list. What exists, which store holds it, who can read it, who can rotate it. Not the secret itself in a document.
- The first-night note. What usually breaks, what to check first, and who to call if it is the vendor.
Access comes off the people who are leaving. Their keys, their admin, their laptop vault. If the only copy of a secret walks out the door, you did not launch. You rented uptime.
This is the same seat as a fractional CTO conversation. Someone who will sit in the room and say the blank row out loud before the contract ends. Not a slide about operations. A name.
Write the list, or bring someone who will
A small team can do this themselves. The founder who still ships, or the engineering lead, writes the rows and tries the rollback on a Tuesday. That is enough when the list is short and the names are real.
Bring someone in when the list is still a feeling. The build team is about to roll off. Nobody can say who is on call Friday night. That conversation is CTO advisory. Thirty minutes is enough to tell whether the handoff is written or still a hope.
Do not start a new build to avoid the list. A rewrite does not answer the page. The system that is up tonight still needs an owner.
Same idea, other angles
The night something breaks is the same night. The seat changes.
- Who owns the app after launch, on Maxiom Apps. Store updates, crash reports, and who picks up the phone.
- Who owns the code after the contract ends, on Maxiom Dev. Repos, access, and a clean handoff so your team keeps shipping.
- Who owns PHI systems after go-live, on Maxiom Labs. Access, logs, and the team that answers when patient data is the issue.
FAQ: who owns production after launch
Who should own a system in production?
One person who can deploy it, roll it back, and say where the secrets live. A backup person with the same access. "The team" is not a name. The company that built it is not the owner after they leave, unless the contract still puts them on the page.
What does on-call have to include?
A rotation, a phone number, and a backup when the first person does not answer. The page goes to that number. A shared channel where everyone assumes someone else saw it is not on-call.
What has to be true about deploys?
More than one person can run the path, including on a bad night. Rollback is written and has been tried. If only the person who built it can ship, you do not have a deploy. You have a dependency.
Where should secrets live?
In a store the on-call account can read, with a list of who else can read them and who can rotate them. Not in a personal password manager, a chat thread, or a laptop that is about to leave.
What should the build team leave behind?
Owners and backups. A deploy path a second person can run. A rollback you have tried. A secret list that does not contain the secrets. A short note on what usually breaks first. Then their own access comes off.
What if a vendor runs the servers?
You still name an owner inside your company. That person can open the vendor ticket, revoke the vendor, and keep the system up if the vendor does not answer. The vendor can be on the list. The vendor cannot be the only name.
Is this the same problem as technical debt?
No. Debt is the calendar cost of a shortcut, the week that became a quarter. This is who is awake when production breaks after the build team moves on. You can have a clean codebase and still have no owner. You can have an owner and still be slow. If the pain is the weeks, read the real cost of technical debt.
When should we bring someone in?
When the build team is about to leave and the rows are still blank. That is CTO advisory: a person who will name the owner, the backup, the deploy, and the secret store before the first night. If you can already point at those names, you can run the handoff yourselves.
If you want that conversation, see CTO advisory or talk to an engineer. Thirty minutes is enough to tell whether the list is real.
I write from the seat of a working engineering company, not a tool vendor. More at antoniochagoury.com.
