Most freelance project problems (late feedback, missing logins, surprise requests) can be traced back to the first week. A clear freelance client onboarding process sets expectations before work starts and gives the client confidence they hired the right person. This guide walks through the system I recommend: a welcome pack, a kickoff call agenda, a secure access checklist, communication cadence, a project board, milestones and reusable templates.
What client onboarding is (and when it starts)
Onboarding is everything between “yes, let’s do it” and the first real piece of work. It starts the moment the contract is signed and the deposit is paid, not before. Starting work on a verbal yes is how you end up building things nobody agreed to pay for.
A good onboarding process has three goals:
- Alignment – both sides agree on scope, deliverables, timeline and who decides what.
- Access – you have every account, asset and piece of content you need, granted safely.
- Rhythm – the client knows when they will hear from you, where to find progress and how to give feedback.
If the contract itself is still loose, fix that first; my guide to freelance web developer contract essentials covers the clauses onboarding depends on.
The welcome pack
Send a welcome pack within a day of signing. It can be a short PDF, a shared document or a page in your client portal. The point is that the client has one place to look instead of searching through email threads. Mine covers:
- A short thank-you and what happens next – the next three steps with dates.
- Project summary – scope in plain language, with a link to the signed proposal.
- Timeline and milestones – key dates, including the client’s own deadlines for feedback and content.
- How we communicate – channels, response times, working hours and time zone.
- What I need from you – the access and content checklist, with a due date.
- How feedback and changes work – rounds of revisions, and how requests outside scope are handled.
- Invoicing – payment schedule, how invoices arrive and payment terms.
Keep the tone friendly but specific. “I’ll reply within one working day” is better than “I’m always available”, which you cannot sustain and should not promise.
The kickoff call agenda
A kickoff call turns the documents into a shared understanding. Send the agenda in advance and ask the client to bring every decision-maker; a stakeholder who appears at the review stage with new opinions is one of the biggest risks to a timeline.
kickoff_call:
duration: 45-60 minutes
attendees: [client decision-maker, day-to-day contact, me]
agenda:
- intros_and_roles: who approves what, who is the single point of contact
- goals: what does success look like in measurable terms
- scope_walkthrough: confirm deliverables, call out what is NOT included
- users_and_content: audience, who writes and supplies content, deadlines
- technical: hosting, domain, existing integrations, analytics
- timeline: milestones, review windows, holidays on both sides
- communication: channels, cadence, response times
- risks: anything that could delay us, agreed owners
- next_steps: actions with owners and dates
after_the_call:
- send written recap within 24 hours
- update project board with all action itemsThe written recap matters as much as the call. It turns spoken agreements into something you can both point to later, and it is the first defence against scope creep. More on that in my guide on how to handle scope creep.
The access and credentials checklist
Missing access is the most common reason a project stalls in week one. Ask for everything at once with a clear checklist and a due date, and be strict about how access is shared.
Security rules I follow
- No passwords over email or chat. Ask the client to share credentials through a password manager’s sharing feature, or better, to invite you as a user.
- Least privilege. Request your own account with the minimum role needed (for example an editor or developer role, not the owner login). Your own account means activity is attributable and access can be removed cleanly.
- Two-factor authentication. Enable it on every account created for you, and do not ask clients to disable theirs.
- Revocation at the end. Put access removal on the offboarding checklist so the client knows it will happen.
access_checklist:
hosting:
- control panel: own user account, developer role
- SFTP/SSH: key-based access, my public key added
domain_and_dns:
- registrar or DNS provider: delegated user, not owner login
website:
- CMS admin: personal account, admin only if required
- staging environment: URL and access method
code:
- repository: invite to organisation, write access to project repo only
third_party:
- analytics: user with edit or read access as needed
- search console: user added to property
- email/transactional service: API key created for this project
- payment gateway: test-mode keys for development
content_and_brand:
- logo files, brand guidelines, fonts and licences
- copy, images and product data with owners and due datesTreat client data and credentials as a liability, not just a convenience. Store them only in your password manager, never in project notes or repositories, and keep environment-specific secrets out of version control.
Communication cadence
Clients rarely complain about too little code; they complain about not knowing what is happening. Agree a cadence and stick to it:
- One primary channel. Email, a shared Slack channel or the project tool’s comments, but one place for decisions. Side conversations in other apps get lost.
- A weekly update. Same day each week: what was done, what is next, what you need from them, and any risks. Short and skimmable.
- Milestone reviews. A call or recorded walkthrough at each milestone, with a clear feedback deadline.
- Response time expectations. State your working hours and typical reply time, and how to reach you for genuine emergencies once the site is live.
weekly_update_template:
subject: "[Project] Weekly update – week of {date}"
sections:
done_this_week: 3-5 bullet points with links to preview
next_week: planned work
needed_from_you: items with due dates
risks_or_blockers: anything that could move a milestone
milestone_status: on track / at risk, with reasonThe project board
A shared board gives the client a live view without needing to ask. Trello, Notion, Linear, GitHub Projects or ClickUp all work; the tool matters less than the structure. I keep columns simple:
- Backlog – agreed scope, broken into tasks.
- Waiting on client – content, decisions and access you need. This column makes delays visible and fair.
- In progress – what you are working on now.
- Ready for review – with a link to staging and what to test.
- Done – approved items.
- Change requests – anything outside scope, estimated separately before it moves into the backlog.
For a comparison of tools that fit a solo developer, see my post on freelance developer workflow tools.
Milestones and approvals
Break the project into milestones that each end with something the client can see and approve, for example: discovery and sitemap, design, development on staging, content entry and QA, launch. For each milestone, define:
- The deliverable and how it will be presented.
- The review window and the number of revision rounds included.
- What “approved” means (a written confirmation in the agreed channel is enough).
- Whether a payment is tied to it.
Tying payments to milestones keeps cash flow steady and gives both sides natural checkpoints. Agree upfront what happens if client feedback is late: the timeline moves accordingly, and you note it in the weekly update.
Templates that make onboarding repeatable
The real gain comes from doing this the same way every time. Build a small template library and refine it after each project:
- Welcome pack template with placeholders.
- Kickoff agenda and recap email.
- Access checklist per project type (WordPress, WooCommerce, headless, web app).
- Weekly update template.
- Milestone approval message.
- Offboarding checklist: handover documents, access revocation, backups confirmed, final invoice, request for a testimonial.
A small script can set up the same folder structure for every new client, so documents always live where you expect them:
#!/usr/bin/env bash
# usage: ./new-client.sh "acme-co"
set -euo pipefail
CLIENT="$1"
BASE="$HOME/clients/$CLIENT"
mkdir -p "$BASE"/{01-contract,02-onboarding,03-assets,04-design,05-meetings,06-handover}
cp ~/templates/welcome-pack.md "$BASE/02-onboarding/"
cp ~/templates/access-checklist.md "$BASE/02-onboarding/"
cp ~/templates/kickoff-agenda.md "$BASE/05-meetings/"
echo "Created $BASE"Key takeaways
- Start onboarding only after the contract is signed and the deposit is paid.
- Send a welcome pack that covers scope, timeline, communication, client responsibilities and invoicing.
- Run a structured kickoff call with every decision-maker and send a written recap.
- Collect access through a password manager or personal accounts with least privilege, and plan revocation from day one.
- Use a weekly update, a shared board with a “waiting on client” column and approved milestones to keep projects on track.
Frequently asked questions
How long should freelance client onboarding take?
For a typical website project, the welcome pack, kickoff call and access collection can usually be done within the first week. The real constraint is how quickly the client supplies access and content, which is why the checklist needs a due date.
How should clients share passwords with a freelancer?
Ideally they create a personal account for you with the minimum role needed, so no password is shared at all. When a credential must be shared, use a password manager’s secure sharing feature, never email or chat.
What should a freelance welcome pack include?
A summary of scope, the timeline and milestones, communication channels and response times, the client’s responsibilities with due dates, how feedback and change requests work, and the invoicing schedule.
Do small projects need a formal onboarding process?
Yes, but it can be lighter: a short welcome email, a brief kickoff call and the access checklist cover most small projects. The structure prevents the same misunderstandings regardless of project size.
Looking for a developer who runs projects this way from day one? Get in touch and tell me what you are planning.
