In the past 5 years I've helped at least seven founders recover from the same disaster: their developer disappeared, and they couldn't deploy the site, couldn't access the database, couldn't change the domain settings, couldn't even reset a customer's password. The recovery in each case took weeks of forensic work and significant cost. In two cases the founder had to rebuild from scratch because the original code was effectively gone — owned by someone they couldn't reach.
Each disaster was completely preventable. Each one was caused by skipping the same three setup decisions at the start of the engagement. The decisions take less than an hour to make. Skipping them costs months of recovery.
This article is the explicit setup checklist. If you're already in a developer engagement and you don't have all three of these in place, fix it this week.
The first thing: code in your GitHub
Not the developer's. Not "shared." Not on the agency's BitBucket. Your account, your organisation, your repository, with the developer added as a collaborator with write access.
Why this matters
The code that runs your business has to live somewhere you control. If it lives somewhere the developer controls, three failure modes become possible:
Failure mode 1: The developer disappears. Life happens. People get sick. Some freelancers ghost. If the code is in their account and they're not responding, you have no way to deploy fixes, ship features, or rebuild your environment. Your business stops while you try to recover the code.
Failure mode 2: The developer terminates the engagement. Sometimes relationships end badly. If the code is in their account, they have the technical ability to revoke your access or even delete the repository. I've seen this happen exactly once, and it was a $40,000 disaster for the client.
Failure mode 3: The agency goes out of business. If you're working with an agency and the code lives on their BitBucket, when the agency shuts down (which agencies do), your code may be in legal limbo for months while creditors fight over the agency's assets.
In all three cases, the legal contracts you have should protect you, but practical recovery is hard. Even if the developer's contract assigned IP to you, getting a copy of the code without their cooperation requires lawyers. The legal right to the code doesn't help if you can't physically get the code.
The setup that prevents this
Specific steps:
- Create a GitHub organization in your name (e.g.,
acme-inc) before any code is written. Pay for the team plan ($4/month/user) so you can manage permissions properly. - Create the repository inside that organization, not on the developer's personal GitHub.
- Add the developer as a member of the organization with write access to the specific repository.
- Don't give them owner permissions on the org. Owner can delete repositories, change permissions, transfer ownership. Member with write access on a repo can do their work and nothing more.
- Enforce branch protection on the main branch — require pull requests, require at least one reviewer (you, or a senior dev). This way nobody can force-push or delete history.
- Enable backups via GitHub's settings or use a third-party service like BackHub. GitHub itself can have outages; your code should exist in at least one other place.
Total setup time: 30 minutes. Cost: $4/month. Protection: complete.
What if the developer pushes back?
Some developers prefer to use their own GitHub account during the engagement. They have a workflow they like, their tools are configured for it, they don't want to learn yours. Some agencies have policies that all client work goes on their BitBucket.
The pushback isn't malicious. But it's wrong, and you should hold the line. Polite responses to common pushback:
"I understand. For business continuity reasons, I need the code to live in my GitHub organization. I'll add you as a collaborator so the workflow is identical for you — you'll work in the same way, just with the repo in my account."
If the developer or agency refuses to work this way, they're either inflexible (find a different developer) or hiding something (definitely find a different developer). This is a non-negotiable line. Holding it from day one prevents the entire category of disaster.
The second thing: hosting and domain in your accounts
Your Vercel deployment lives under your Vercel account, not the developer's. Your domain is registered in your name. Your DNS is managed in your account. Your SSL certificates auto-renew on your billing.
Why this matters
Same logic as the code. If the hosting account belongs to the developer, you're locked out when they disappear. If the domain is registered in their name, they technically own the domain — and ICANN's rules around domain transfers can take 60+ days even when both parties cooperate, longer when they don't.
Specific failures I've seen:
The developer sets up the Vercel account using their own email. Six months later they leave. The new developer can't deploy because Vercel sends 2FA codes to the original developer's phone. The site can't ship updates for 3 weeks while the founder convinces Vercel support to transfer the account.
The domain is registered with the developer's GoDaddy account. When the engagement ends, the developer is "happy to transfer" but their reseller account requires confirmation steps, the domain has 60-day registrar lock, the founder loses 3 months of marketing momentum.
The Stripe account is in the developer's name. This is the worst category. If your payments processor is in the developer's name, they technically own the customer relationship and the money flow. Untangling this when the engagement ends is a months-long project that may require a Stripe migration with downtime.
The setup that prevents this
Before any service is set up, decide which accounts will be involved. Then set them up in your name, with your billing details, before granting the developer access.
Specifically:
- Domain registrar (Namecheap, Cloudflare, Google Domains): in your name, with your credit card.
- Hosting platform (Vercel, Render, Heroku, etc.): in your business email, with your billing.
- DNS management (Cloudflare, Vercel, AWS Route53): in your account.
- SSL (usually managed automatically by the hosting platform): tied to your account.
- Email service (Postmark, SendGrid, SES): in your business name.
- Payment processor (Stripe, Paddle): in your business name with your bank account.
- Analytics (Google Analytics, Plausible, Fathom): in your account.
- Monitoring (Sentry, BetterStack): in your account.
- Customer support (Intercom, HelpScout): in your account.
Each of these takes 5–10 minutes to set up. The developer gets invited as a team member with appropriate access (admin, developer, or read-only depending on the service). When the engagement ends, you remove their access. Nothing changes hands; nothing needs to be transferred.
The "but I don't know how to set these up" objection
You don't need to know the technical details. Most of these services walk you through setup in a few minutes. The developer can guide you through which choices to make.
The pattern: you sign up and create the account, and they tell you which buttons to press. This way the account is yours, but you got their expertise on the configuration. They can have full administrative access via team invitations; the underlying account stays in your name.
If a developer offers to "set this up for you using their account, then transfer it later," decline politely. Transfers are messy. Set up in your account from the start.
The third thing: customer data in your control
Database credentials, customer lists, payment records, analytics. The developer needs access to do their work; they don't need ownership.
Why this matters
Your customer data is the most valuable thing your business owns. It's also the most legally sensitive, especially in jurisdictions with GDPR (Europe), CCPA (California), or the Privacy Act 1988 (Australia). Data breaches caused by mishandled access become your legal problem, not the developer's.
Failure modes:
The developer has the database password in their personal password manager. When they leave, they technically still have access to your customer data. The contract says they shouldn't use it, but the technical access remains. If they're hit with their own data breach, your customer data is in the blast radius.
The developer's local development environment has a copy of production data. Common pattern for debugging. Months after the engagement ends, that database dump is still on their laptop. If their laptop is stolen, you have a data breach to disclose.
The developer used their own AWS or Stripe account for setup, and customer data flows through it. Same problem at a service level — your data is touching infrastructure you don't control.
The setup that prevents this
Three principles:
Principle 1: Use a shared password manager. Every credential the developer needs goes into a shared 1Password / LastPass / Bitwarden vault. They access credentials through the vault; they never paste passwords into their personal password manager. When the engagement ends, you revoke their vault access in 30 seconds and rotate the credentials they had access to.
Principle 2: Don't use production data in development. The developer should have a separate development database with anonymised or synthetic data. They never have a local copy of real customer records. This is a security hygiene practice that's also strongly encouraged by every privacy regulation.
Principle 3: All data flow goes through your services. Stripe is in your name. Your hosting database is on your account. Your S3 bucket is in your AWS. The developer accesses them through invitations to your accounts; the underlying data never leaves your infrastructure.
If the developer needs to debug a customer-specific issue, they request specific information from you (or a senior team member with proper authorisation) rather than accessing the data directly. This sounds like friction; it's actually a healthy practice that mature companies follow.
What if you've already broken these rules?
If you're partway through an engagement and you don't have these three things in order, fix it now. The fix is straightforward:
- Create a GitHub organization in your name. Have the developer push the latest code from their repo to your new repo. Once verified, archive their version.
- Create new accounts in your name for any service that's currently in the developer's name. Migrate one at a time. The developer can guide you through each migration.
- Create a shared password vault and put all credentials there. Have the developer access future credentials only via the vault.
- Rotate all credentials at the time of cutover, so the old setup loses access cleanly.
This is a 1–2 week project, depending on how much infrastructure already exists. Doing it now is much cheaper than doing it during a crisis. The cost of doing it now is some friction with the developer; the cost of doing it during a disaster is weeks of business disruption.
What to do next
The companion articles cover related setup work:
- International Contractor Contracts: What Matters and What's Theater (the legal layer that complements these technical practices)
- Working With Your Developer Without Becoming a Project Manager
If you'd like to talk about a specific engagement and how to set it up properly from day one, the first call is free — see Full-Stack for SaaS Startups or Bootstrappers.
---
Part of the Full-Stack Development for Solo Founders pillar guide.