How to Send Logins to Your Web Developer Safely
Sending a website login by email or WhatsApp leaves a permanent password sitting in a chat log. Here's how to hand access to your developer safely instead.
Why email, WhatsApp, and Slack are the wrong place for a password
None of these tools were built to hold a secret. They were built to hold a conversation, and a password typed into a conversation behaves exactly like the rest of it: it gets backed up, synced across every device, searched, and sometimes forwarded by accident when someone quotes an old thread.
A password sent by email doesn't go away when the project finishes. It stays in your Sent folder, in your developer's Inbox, on both of your phones if mail is synced there, and in any backup either of you has ever taken — indefinitely, in plain readable text. WhatsApp encrypts the message in transit, which sounds reassuring, but the outcome is the same: the message never expires, and a phone left unlocked on a café table shows your password to whoever picks it up. A shared Slack or Teams channel is no better — a password pasted into a channel sits there for as long as the channel exists, visible to everyone who has access now or is added later.
None of this requires anyone to do anything malicious. It just requires the password to keep existing somewhere you've stopped thinking about.
The safer ways to hand over access, best first
1. Give your developer their own account
Almost every platform that matters — your hosting panel, WordPress, Google Analytics, your domain registrar — lets you invite a second person with their own login and their own permission level, instead of sharing yours. This is the best option whenever it's available, because it answers two questions cleanly: what can this account do, and how do you make it stop existing when the project ends? You never have to tell anyone your actual password, and removing access later is one click, not a password change.
Look for "Users," "Team," or "Collaborators" in the platform's settings. If your developer asks for admin access and the platform supports roles below Administrator, it's worth asking whether a narrower role would do the job instead.
2. Share one entry from a password manager
If you already use 1Password, Bitwarden, or a similar tool, you can share a single entry with your developer without ever typing the password anywhere. They get access to that one item; you can revoke it with a click; the value never lands in an inbox. The catch is that this only works if you're already set up with a password manager — it's not something worth adopting for a single handoff, and it still hands over your actual, ongoing password rather than something scoped just to the project.
3. A one-time link that shows the password exactly once
Some tools exist specifically to pass one secret safely: you type it into a page that encrypts it immediately, your developer opens a link and sees it exactly once, and after that, nobody — including you, reopening the same page — can see it again. It never sits in an inbox, because it's never inside an email to begin with. This is the right fallback when a platform genuinely has no way to invite a second user — a hosting account with a single login and no multi-user support, for instance.
4. A client portal built for the whole handoff
If your developer is already using a tool to collect your logo, your text, and other project materials, credentials can go through the same channel rather than a separate message. That's the option below, and it's the one BriefGate is built around.
After the project ends: revoke it
Handing over access is the easy part. What happens afterward is where most of the actual risk sits, because a forgotten collaborator account is a working login nobody is watching.
- Remove the account you created for your developer once the work is done — don't leave it "for later."
- Change the password on anything that was ever typed into an email or a chat message, even briefly, even if you've since moved to something safer.
- Check that you still hold the original owner account — your hosting login, your domain registrar, your payment provider — so nothing about your business depends on someone else's account staying active.
- If a password went out insecurely before you read this, it costs nothing to change it now. The gap only closes when you close it.
How this works if your developer uses BriefGate
If your developer has sent you a BriefGate portal link along with a request for logins or an API key, here's what happens on your side. The item is marked with a lock icon and a note that it's shown only once. You type the value into a masked field — the same way you'd type a password anywhere else — and it travels over HTTPS to BriefGate's server, where it's immediately encrypted (a public-key sealed box) before it's ever written to a database. The plaintext is never stored — only the encrypted version is kept.
Your developer (or their coding agent) retrieves it exactly one time. The instant that happens, the plaintext is gone from BriefGate's side — not hidden, not archived, actually gone. If you reload the same page afterward, there's nothing to see; the field simply shows that it's already been delivered. There's no way for you, for BriefGate, or for anyone else to pull that value back up a second time.
One practical detail: if nobody retrieves the credential within 30 days of you submitting it, it expires on its own and can't be recovered. If that happens, your developer will ask you to enter it again — it's not a sign anything went wrong, just the same one-time design working as intended.
If you're the developer on the other side of this handoff, the companion guide on asking clients for logins securely covers the same process from your point of view — including how to phrase the request so it doesn't read like a security lecture.