In short
Don’t share your logins. Give the client access to their site only, choose a role (edit only, or edit and publish), keep a staging step for changes that matter, and keep the site as files you can hand over. Then, when the relationship changes, you remove one person from one site and nothing else is affected.
The problem with sharing a login
The quickest way to let a client update their site is to send them your login. It’s also the riskiest:
- They can see and change everything on that account, including other clients’ sites.
- You can’t tell who changed what.
- When the work ends, you have to change the password and update it everywhere else it’s used.
- If they forward it to a colleague, you have no idea who has it.
Creating separate accounts on every service helps, but it multiplies the admin: a hosting account, an editor account, a domain account, each with its own permissions.
What a good handoff looks like
A clean handoff has four parts.
1. Access to one site, not an account
The client should be able to open their site and nothing else. They shouldn’t see your other clients, your billing or your settings. In Devdwell you share a single site by email; the person you invite sees that site under “Shared with me” and nothing more. See sharing.
2. A role that matches the job
Most clients want to change words and pictures, not publish untested changes to their live site. Two roles cover nearly every case:
- Can edit: they make changes; you check and publish. A good default.
- Can edit and publish: they can also put changes live. For clients who are confident, or after a few weeks of “Can edit”.
3. A check before going live
Even with a careful client, a staging step saves awkward moments. Publish their change to a private staging link, look at it on your phone, and publish to production when it’s right. More in why check a staging version before you publish.
4. A clean exit
At some point the relationship changes: the project ends, they hire someone in-house, or they want to take the site elsewhere. Plan for it from the start:
- Removing someone should be one action that doesn’t affect anyone else.
- The site should be ordinary files you can hand over, not something locked inside one platform.
- The live site should keep working while you hand it over.
Step by step with Devdwell
- Open the client’s site in Devdwell.
- Open its sharing and type the client’s email.
- Choose “Can edit” (or “Can edit and publish”).
- Send the invite. They sign in with their email and a six-digit code, so there are no passwords involved.
- When they make changes, you see them in the site’s activity; publish when ready.
- When the work ends, remove them from the site, or hand over the files.
The full walk-through is in how to share a website with a client.
What to tell the client
Clients don’t need a manual; they need three sentences:
- “You’ll get an email from Devdwell. Sign in with your email; there’s no password.”
- “Open your site, describe the change you want, and you’ll see it in the preview.”
- “I’ll check it and put it live,” or, if they can publish, “press Publish when it looks right.”
A handoff checklist
- No shared passwords, anywhere.
- Client has access to their site only.
- Role chosen deliberately: edit, or edit and publish.
- Staging used for anything customer-facing.
- You can remove access in one step.
- The site exists as files you can hand over.