How to give a developer access without sharing passwords

Giving a developer your own login feels quick, but it hands over everything: billing, ownership settings and the ability to lock you out. Almost every service a modern app depends on has a way to invite another person with their own account and a limited role. This guide explains what to use on the most common services, what to do when there is no team feature, and how to close access cleanly when the work ends.

Four rules that apply everywhere

1. You own the account. The project's accounts should be in your name or your company's name, with your email and your payment card. The developer joins as a guest, never as the owner.
2. One person, one login. Each developer signs in with their own account and their own two-factor sign-in. You can see who did what, and removing one person does not affect anyone else.
3. Smallest role that works. Give the role needed for the current task. Owner, billing and payout rights stay with you.
4. Plan the exit on day one. Keep a list of every invite you send. When the work ends, that list becomes your removal checklist.

Exact menu names change from time to time, so the sections below describe what to look for rather than every click.

Code: GitHub and similar hosts

On a repository owned by a personal GitHub account, you can add collaborators, and they receive write access. Personal repositories do not offer finer roles, but the developer cannot change ownership or delete the repository.

For more control, create a free GitHub organisation and move the repository into it. Organisations let you give each person a role per repository: Read, Triage, Write, Maintain or Admin. Write is enough for most development work. You can add someone as an outside collaborator on a single repository without making them a member of the whole organisation.

Two extra settings help:

• Branch protection on your main branch, so changes arrive through pull requests you can review.
• No shared deploy keys or tokens. The developer uses their own GitHub account and their own SSH key.

GitLab and Bitbucket offer similar project member roles.

Hosting: Vercel, Netlify and Cloudflare

Vercel handles collaboration through teams. The free Hobby plan is meant for personal use, so inviting members generally means using a paid team plan. Team roles range from owner down to view-only, with roles in between that can deploy without managing billing or the team itself.

Netlify also uses teams with roles such as Owner and Developer, plus a reviewer-style role for people who only need to see previews. Some roles depend on your plan, and extra members may add cost.

Cloudflare lets you invite members to an account and give them roles. Besides full administrator access, there are narrower roles, such as roles limited to DNS or analytics, and on some plans you can limit a member to specific domains.

Database and backend: Supabase and Firebase

In Supabase, people are invited to an organisation and given a role such as Owner, Administrator, Developer or Read-only. A Developer can work on projects but cannot manage billing or delete the organisation. Some plans also allow access to be limited to particular projects. Remember that most members can read the project's API keys, including the service role key, which matters when you remove them later.

Firebase projects use Google Cloud permissions. In the project settings you will find a users and permissions area where you can add a Google account with a basic role (Owner, Editor or Viewer) or a narrower Firebase product role. Editor is usually enough for development. Keep Owner for yourself.

Domain and DNS

Registrars differ a lot here. Some offer delegate or shared access, which lets another person manage DNS or settings on your domains without your password. Many registrars have nothing comparable.

If your registrar has no safe option, you have two good alternatives. You can keep the registrar to yourself and make DNS changes when the developer sends you the exact record to add. Or you can move DNS hosting to a service with member roles, such as Cloudflare, while the domain stays registered in your account. Never transfer the domain itself into a developer's account.

Payments: Stripe

Stripe lets you invite team members and choose a role for each. Roles include Administrator, Developer, Analyst, Support Specialist and View Only, among others. The Developer role is designed for technical work such as API keys, webhooks and logs, without the Administrator's power over the account's business and payout settings.

Much payment work can be built and tested in test mode before anyone touches live payments. Where a separate system needs to call Stripe, a restricted API key with only the permissions it needs is safer than a full secret key.

Mobile apps: App Store Connect and Google Play Console

In App Store Connect, invite people from the users and access area. Roles include Admin, App Manager, Developer, Marketing, Finance, Sales and Customer Support, and many roles can be limited to specific apps. App Manager is the usual choice for someone who needs to submit a particular app for review. The Account Holder role belongs to whoever enrolled in the Apple Developer Program and should stay with you.

In Google Play Console, the users and permissions page lets you invite someone by email and grant permissions for the whole account or for individual apps. You can choose detailed permissions, for example letting a developer release to testing tracks while keeping production releases and financial data for yourself.

Shopify

Shopify Partners such as freelance developers and agencies can send a collaborator request to your store. You approve it and choose which areas they can access. Collaborator accounts are the standard way to bring in outside developers, and some sensitive areas stay restricted to the store owner whatever permissions you choose. Staff accounts are better suited to your own team members and come with plan-based limits.

WordPress

Create a separate WordPress user for each person rather than sharing the admin login. The built-in roles are Administrator, Editor, Author, Contributor and Subscriber. Installing plugins and editing themes needs Administrator, so if a developer only adds content, Editor is enough.

For code changes, ask your host whether it supports a staging site and separate users for SFTP, SSH or the hosting dashboard. Many managed WordPress hosts let you invite people to the hosting account with limited permissions. That is far better than sharing the hosting panel password.

When a service has no team feature

Some older tools and smaller API providers only offer one login. For those, use a password manager's sharing feature, such as a shared vault or shared item, rather than pasting the password anywhere. You can withdraw the share later and you have a record of what was shared.

Treat this as a last resort. The developer has still seen the credential, so change it when their work ends. For API services, a better option is often to create a separate key just for this developer's work, named clearly, so you can delete it without disturbing anything else.

Never send credentials in chat or email, including TakeoverWork messages. If you suspect a key has already been pasted somewhere it should not be, check the text with the Secret Leak Scanner.

Offboarding: closing access when the work ends

Do this the same week the work finishes, while you still remember every invite:

• Remove the developer from the code host, hosting, database, DNS, payment and app store accounts
• Remove their WordPress or Shopify user or collaborator access
• Revoke deploy keys, access tokens and SSH keys they added
• Check webhooks, integrations and connected apps for anything you do not recognise
• Move anything they created in their own accounts, such as a test project or analytics property, into yours
• Replace API keys and secrets they could read, one service at a time, testing after each change
• Change any password that was shared through a password manager
• Review recent activity logs where the service provides them

When replacing keys, update the hosting environment variable and redeploy before revoking the old key, so the live app never runs without a valid one.

The Project Handover Checklist Generator can produce a written list of every account and the access each person holds, which makes both the invite and the removal steps easier. If the code is in a public repository, the Repo Health Check also shows whether any key-like files were committed while the developer was working.

If access was never set up this way

Many owners only discover these options after a developer stops replying while still holding the passwords. If that has happened to you, read developer disappeared with the code first and secure your accounts. Then set up invites properly for whoever continues the work. You can post your takeover for free and agree access with the developer you choose once you have agreed terms.