Day-one ownership: why your accounts shouldn't live in our agency dashboard

On every project we ship, the client owns the stack on day one. Not after a 90-day handoff, not after a dispute, not after they ask. Day one. This is unusual enough in agency-land that it's worth writing down what we mean by it and why we run things this way.

What "own the stack" means concretely

• The domain is registered to the client's account. Not ours, not a shared agency account, not a registrar we resell. If you boughtyourcompany.com, it's in your Namecheap or Cloudflare or Google Domains account, on your credit card.
• Hosting is in the client's account. Vercel, Netlify, Fly — wherever the project deploys, the project lives in your team account, not ours. We get added as collaborators with the permissions the work requires, and removed at handoff.
• The database is yours. Supabase, Postgres, whatever. Created in your account, billed to your card. We get a service role for the duration of the build.
• Stripe, Resend, Plausible, GA4, every third-party service.Same rule. Created in your account; we're added as collaborators where collaboration is needed.
• The repo is yours. Pushed to your GitHub organization, not ours. We have push access for the build; at handoff we revert to read-only or are removed entirely.
• The code is yours.No proprietary CMS, no "agency framework" you can't fork. The code in the repo is what runs in production; nothing you can't inspect.

The standard agency model, and why we don't use it

The standard agency model is to register the domain in the agency's account, deploy to the agency's hosting, set up Stripe and analytics under the agency's organization, and then bill the client for "hosting" or "maintenance" that includes a markup. The agency holds the keys.

From the agency side, this is convenient — same logins for every project, easier billing, easier support. From the client side, it's a soft form of lock-in. The minute the relationship ends, the client has to migrate the domain, the hosting, the database, every third-party integration, often in a hurry, often without the agency's help. We've seen the migration in both directions and it's ugly both ways.

Day-one ownership eliminates the migration entirely, because there's nothing to migrate.

The handoff document

At launch, we deliver a written handoff document. Plain Markdown, in the repo. It lists every service the project depends on, every account that owns it, every credential that exists (and how to rotate it), and the answer to the "what happens when X breaks" question for each. Not a sales document — a runbook. Future-you, six months from now, when something stops working at 11pm, can read it and find what you need.

The handoff document is one of the things that makes returning clients possible. When you come back to us in two years for a new feature, we re-read the handoff doc the same way you do. It's the project's memory.

Why this is also a stewardship decision

We've described our pricing model as a stewardship decision. Account ownership is the same conviction applied to operations. The client paid us for a build. The build belongs to them — including the keys that operate it. Holding the keys, even passively, even "for their convenience," turns the relationship into something it shouldn't be: a dependency.

We don't want to be a dependency. We want to be a studio you choose to come back to. Day-one ownership is the structural commitment that makes that choice meaningful instead of forced.

What this costs us

Some operational friction. We have to ask for SSO invites, we have to coordinate billing on the client's side, we can't centralize secrets in one vault. None of that is free. We've decided the friction is worth paying so that the relationship can be the right shape.