Secure Client Onboarding for Web Design & Development Agencies

A web build starts with the keys to the client's whole site. Most of them arrive in a chat message.

Kicking off a build or a migration means getting real control of the client's infrastructure: the domain registrar, the hosting or cPanel, the database, the CMS admin, sometimes SSH or a deployment login. Some access you can get the safe way, by having the client add you as a user. But hosting panels, registrars, and legacy CMS logins usually don't have that, so the client does the natural thing and pastes the password into Slack, or emails you the cPanel details.

Now the logins that control the entire site sit in plaintext across a few tools, readable by anyone in those threads, with no expiry and no record of who opened them. Run ten builds a year and that's ten sets of full-control credentials you're quietly liable for. There's a cleaner way to collect them, and the brand assets, in one encrypted request.

What you'll collect

One kickoff request covers the build. The login fields are encrypted end-to-end in the client's browser; the setup details and files go in alongside them:

• Domain registrar and DNS login
• Hosting or cPanel, and SSH / SFTP / FTP for deployment
• Database credentials
• CMS admin (URL, username, password)
• Any third-party service logins the build needs that have no "add a user" option
• Brand assets to start with: logo files, brand guidelines, and page copy
• The signed proposal or contract, if you collect it here

A large media library, a full stock of high-resolution photos or video, is better sent as its own follow-up so the kickoff request stays focused on access and the essentials.

How the intake flow works

When a client signs: Create a project for them and send your standard kickoff request. It opens as a branded page with your agency's name, not a generic form.

They hand over access and assets: Non-sensitive details go in plainly. The credential fields, hosting, registrar, database, CMS, are encrypted in the client's browser before they're sent, so doconvoy stores ciphertext and never sees a readable login. Clear labels and examples mean a non-technical client fills them in correctly instead of guessing.

You start building: Open the submission in that client's project, decrypt exactly what you need, and go. Every access is timestamped.

What your client experiences

A link, a guided form, a few uploads, submit. No account, no app, no jargon they don't follow. For a client handing over the keys to their whole site, watching the form encrypt the hosting password on their own device is what turns "can I just email it?" into a completed request.

Isolation, rotation, and the handoff

Client A's logins are in Client A's project, never mixed with Client B's, never left in a shared channel. When a build ships or a freelancer rotates off, the project's record is your exact checklist of which credentials to rotate or hand back. That's how you run a pipeline of builds without one leaked hosting login becoming an incident.

This is the build view of client onboarding. To set it up, see how to collect website logins from clients securely and what access a web developer needs from a client. For the marketing-access side, see SEO client onboarding. The building blocks are Secure Requests and Workspaces & Projects.