If You Hire a Developer, Make Sure You Can Fire Them: A Non-Coder's Guide to Owning Your Code

There's a moment every non-technical founder dreads. A developer leaves — quits, is let go, disappears — and you discover that the code lives on their laptop, the servers are under their personal account, the domain renews to their credit card, and the passwords are in their head.

You didn't build a company. You built a dependency on one person.

This isn't rare. It happens constantly to small businesses across India, and the pattern is always the same: everything was informal, everything worked, and nobody thought about the exit until the exit was happening. Here's how to make sure you're never in that position, in language that assumes you've never written a line of code.

The mental model: keys, not knowledge

You don't need to understand how your app works. You need to hold the keys. Think of your app as a building. The developer is the contractor who knows how the plumbing runs. You are the owner who has the deeds, the front-door key, and the utility accounts in your name.

If the contractor leaves, you hire another one. They'll take a while to learn the plumbing, but they can get in, and the lights stay on. If the contractor has the deeds and the keys, you're a tenant in your own building.

The six keys you must hold

1. The code repository

Your code should live in a version-control service — GitHub, GitLab, or Bitbucket — in an organisation account that you own, under your email address, with you as the owner. Developers are added as members. When they leave, you remove them, and the code stays.

What to check: Log in yourself. Can you see the code? Is the organisation's billing email yours? Are you listed as "Owner", not "Member" or "Admin"?

If the code is in the developer's personal account, ask them to transfer it to yours today. This is a five-minute operation and any refusal is a red flag.

2. The domain name

Your domain (yourcompany.com) is registered somewhere — GoDaddy, Namecheap, Google Domains. The account should be yours, with your payment method and your email for renewals.

A lapsed domain is catastrophic: your website, your email, your app's connection to its servers all break, and someone else can buy the name.

What to check: Log into the registrar. Is the account email yours? Is auto-renew on with your card?

3. The hosting and cloud accounts

Wherever your app runs — AWS, Google Cloud, Render, Vercel, DigitalOcean, a VPS — the root account must be yours. Developers get their own logins with permissions to do their job; they don't share yours.

What to check: Can you log into the root account? Are the invoices coming to you? If the developer says "it's easier if it's under my account", it is easier — for them.

4. The database

Your users' data is the most valuable and most legally sensitive thing you own. It lives in a database, possibly a hosted one (MongoDB Atlas, Supabase, AWS RDS). Same rule: root account yours.

Additionally: know how to get a backup. Ask the developer to show you, once, how to download a full copy of the database. Write down the steps. Do it yourself once a month. If everything else fails, a backup of the database plus the code is enough for a new developer to rebuild.

5. App store accounts

If you have a mobile app, it's published through an Apple Developer account and a Google Play Console account. These must be in the company's name, with you as the account holder. Transferring an app between accounts is possible but slow and painful; not having access at all means you can't push updates or fix a crash.

6. Every third-party service

Payment gateway (Razorpay, Stripe), email sending (SendGrid, Amazon SES), SMS, analytics, error tracking, AI APIs. Each has an account and API keys. Each account should be yours or the company's, with the developer added as a user.

Keep a list. Service name, what it's for, whose login, monthly cost. Review it quarterly. You will be surprised what you're paying for.

The one document that saves you

Ask your developer to write a handover document — not when they leave, but now, while things are calm. It should cover:

• Where the code is and how to run it locally
• Where it's deployed and how deployment works
• Every service the app depends on, with account details in a password manager you control
• How to take a database backup and restore it
• Known problems and things that are fragile
• What they'd tell the next developer on day one

A good developer will write this in a couple of hours and won't be offended by the request. Frame it as insurance for both of you — if they're hit by a bus, or you are, the business survives.

Passwords

Use a shared password manager (Bitwarden, 1Password) with a company vault you own. Every credential goes in it. Developers get access to what they need. When they leave, you rotate the passwords they had access to — the password manager will tell you which ones.

Never let credentials live in chat messages, spreadsheets, or someone's memory.

The contract

Your agreement with any developer — employee or freelancer — should state in plain terms that all code, designs, and related work belong to the company, that they'll be delivered on request and on exit, and that credentials will be handed over. Most standard Indian employment and freelance contracts have this; check yours does.

This won't stop a bad actor. But it makes the conversation with a lawyer much shorter if you ever need one.

What this costs

An afternoon of setup and a monthly half-hour review. That's it. Against the alternative — weeks of downtime, a rebuild from scratch, or a payment to someone who's holding your business hostage — it's the cheapest insurance you'll ever buy.

Do it this week, not when someone hands in their notice.