Launch day is loud.
Slack threads, screenshots, a toast for “we shipped.” Two quarters later the SSL reminder hits a departed contractor’s inbox, the pricing page still mentions a SKU you killed, and nobody knows who can deploy.
The site did not fail because the stack was wrong. It failed because launch was treated as the end of work instead of the start of ownership.
We do not close a build without a written ownership map: who changes content, who patches the platform, who holds access, and who wakes up when the form dies on a Sunday.
Someone has to hold the keys after the party.
What “owned” means
Owned is not “has the Figma.” Owned is:
- A named role (human, not “the team”)
- A cadence (weekly, monthly, quarterly)
- A tool path (CMS, repo, DNS host, status channel)
- A backup human when the owner is out
- A definition of done for routine work (e.g. “deps updated and smoke-tested”)
If any of those are missing, you have a hobby site with a production domain.
Four lanes that always need a name
Content
Pages, blog, careers, legal, campaigns, asset rights. Marketing usually owns this — until legal copy is involved, then co-own. Unowned content becomes fiction: old metrics, dead CTAs, expired cookies policy dates.
Platform
DNS, hosting, CI, dependencies, CMS/upgrades, redirects, environment variables. Engineering owns this. Orphans here cause the classic “site went down and the only person who knew Netlify left.”
Security and access
Who has production credentials, who gets offboarded, 2FA, secret rotation, dependency CVEs, form spam spikes. Shared between eng and whoever runs IT. Silence here is how former freelancers retain admin.
Incidents
Outage, defacement, payment or lead-form failure, domain expiry. Needs a primary and a backup, a runbook, and a place alerts actually go. “We’ll notice on Twitter” is not a plan.
The handoff document that prevents ghosts
Before final invoice or internal “project closed,” store:
- Architecture one-pager — where it hosts, how it deploys, critical third parties.
- Access inventory — systems and who is on them (and who should not be).
- Content model notes — how to add a page, who approves.
- Monitoring list — uptime, SSL, form success rate, Core Web Vitals if you track them.
- Vendor renewals — domain, DNS, CDN, analytics, CMS seats, certificate.
- Incident runbook — first five steps, escalation, public status language.
No novel required. Six artifacts beat a Notion graveyard of meeting notes.
Cadence beats heroics
Healthy ownership is boring on purpose:
| Cadence | Work |
|---|---|
| Weekly | Content accuracy pass on money pages; spam queue |
| Monthly | Dependency/CMS updates; access review; backup restore test |
| Quarterly | Performance sample; SEO crawl of key templates; disaster drill |
| Yearly | Domain/DNS renewal audit; full dependency major-version plan |
Heroic weekend fixes are a smell. They mean the calendar was empty.
Agency, in-house, or hybrid
In-house works when you have eng capacity and a marketing owner who actually publishes.
Retainer / maintenance partner works when you want named response times without hiring a full web team — if the contract lists the four lanes, not “we’ll help if something breaks.”
Hybrid is common: marketing owns content in CMS; partner owns platform and incidents; security reviews quarterly together.
What fails: “We’ll call the freelancers if needed” with no contract, no access list, and no SLA.
Product apps vs marketing sites
App ownership includes release trains, feature flags, and on-call for APIs. Marketing site ownership is lighter but still real: content truth, form reliability, SEO hygiene, dependency drift.
Do not pretend a brochure site needs a 24/7 SRE army. Do not pretend it needs zero hours either. Budget hours per month explicitly. Unbudgeted work becomes unpaid heroics or silent rot.
Ownership is the thread through the weeks after launch — not a single red-letter day.
Red flags at “we’re done”
- Deploy keys only on one laptop
- Domain in a personal registrar account
- No staging environment and no way to test content
- Analytics and ads tags owned by a departed agency
- SSL and uptime alerts going nowhere
- “The developer will remember how redirects work”
Any one of these is a future outage with a calendar invite.
A closeout checklist we use
- Ownership table filled (content, platform, security, incidents).
- Access inventory reconciled; leavers removed.
- Runbook linked from the company wiki, not buried in chat.
- Monitoring destinations verified with a test alert.
- Backup/restore touched once in the last 90 days.
- Dependency update path documented (who runs it, how often).
- Content owner trained on the real CMS workflow.
- Budget line for ongoing hours or retainer exists.
If item 8 is missing, ownership is wishful thinking.
Closing
Launch is a milestone. Ownership is the product after the milestone.
Write names, cadences, and runbooks while the build team still has context. That is cheaper than archaeology during an outage — and more respectful than handing a client (or your future self) a live URL with no keys attached.
If your project plan ends at “go live,” extend it by one page: who keeps it alive. That page is the difference between a launch and a liability.
Need a maintenance plan or a post-launch ownership map? Start a project inquiry with who you think owns content today and who gets the 2 a.m. call. Gaps in that sentence are the scope.