Agency Client Onboarding: The First 30 Days

The kickoff meeting feels like the beginning of a project. In practice, it’s a checkpoint in the middle of onboarding, not the start of it. By the time you’re in that meeting, you’ve already won or lost the next three months.

Bad onboarding follows a recognizable pattern: the contract is signed, the retainer clears, and the agency dives into the work. Weeks later, the client is confused about what’s being built. The team is confused about what the client actually needs. Everyone is too busy to have the conversation that should have happened in day one.

Good onboarding is deliberate, slightly slower at the start, and much faster for the rest of the engagement. The first 30 days are an investment in shared understanding. Here’s how we structure them.

Before Day 1: The Pre-Kickoff Packet

The kickoff meeting shouldn’t be the first time the client sees how you work. Send a pre-kickoff packet 3-5 days before the first meeting. It takes 30 minutes to prepare and saves three meetings’ worth of confusion.

The packet includes:

Project brief (written by you): Your understanding of what you’re building, who it’s for, and what success looks like. Written in plain language. This forces you to articulate what you think you’re building, which invariably surfaces misalignments before work starts. The client will correct things. That’s the point.

Communication norms:

• How the team communicates day-to-day (Slack, email, project management tool)
• Meeting cadence and expected meeting length
• Response time expectations (replies within one business day is reasonable; the client should set their own expectation too)
• Who the primary contact is on each side

Access checklist: A list of everything you’ll need: domain registrar, hosting credentials, design tool access, analytics access, GitHub organization invite, API keys for third-party services. Send this before the kickoff so you’re not waiting on access during week one.

Decision log template: Introduce the concept of a decision log now. Every significant technical or design decision gets recorded with the decision made, the alternatives considered, and why you chose this direction. Clients who review this regularly have fewer “wait, when did we decide that?” moments.

Week 1: Foundations

The goal of week one is access, alignment, and environment setup. No feature work starts this week.

Kickoff meeting (90 minutes):

Structure it with an agenda sent 24 hours in advance. Cover:

• Project goals and what “done” means, in the client’s words
• Who makes decisions on each side (ambiguity here causes delays)
• Timeline walk-through, including dependencies and milestones
• Open questions (you will have some from the brief)
• Next steps with owner and date for each

Record the meeting with permission. Recordings aren’t for surveillance. They’re for the new team member who joins in month two, or for the brief you’ll write afterward.

Write the kickoff summary: Same day or the next morning. The summary is the written record of what was agreed in the meeting. It includes decisions made, open questions with assigned owners, and any changes to the project scope or timeline. Send it to everyone in the meeting and ask for corrections within 48 hours. This is not bureaucracy; it’s the mechanism by which verbal agreements become reliable records.

Environment setup: Get the development environment documented and running by end of week one. Every team member should be able to clone the repo and have the app running locally with no additional help. Write the README as you go, not after. If setup takes more than 20 minutes following the documented steps, the setup is too complicated or the documentation is incomplete.

Week 2: Discovery and Architecture Decisions

You now have access to the client’s systems and a shared understanding of what you’re building. Week two is for discovery: understanding what exists, what constraints apply, and what decisions need to be made before development begins.

Technical audit: If you’re inheriting existing code or infrastructure, spend two to three days understanding it before writing anything new. What’s the deployment model? What external services does it depend on? Are there known performance problems or security issues? Are there parts of the codebase that have been stable for years (don’t touch) and parts that are actively changing (coordinate closely)?

Write down what you find. Even a bullet-point summary shared with the client builds trust and surfaces things the client didn’t realize mattered.

Architecture decision records: For any significant technical decision made during discovery, write an ADR: the context, the decision, the alternatives considered, and the consequences. ADRs don’t need to be long; a half-page each is fine. The goal is that six months from now, when the team asks “why is the auth system structured this way?”, there’s a written answer.

Design review (if applicable): If you’re working from designs, schedule a walkthrough with the designer and product stakeholders before development starts. Cover every screen that has interactive states, edge cases, or data dependencies. Questions that surface here take 10 minutes to resolve. The same questions surfacing mid-development take 10 hours.

Week 3: First Deliverable

By the end of week three, the client should see something: not the full product, but a working slice of it.

What qualifies as a first deliverable depends on the project:

• For a web application: the authenticated shell, where a user can sign up, log in, and see a dashboard (even if the dashboard is empty)
• For an integration project: the first data flow working end-to-end, even if it only handles the happy path
• For a design project: reviewed wireframes for the core user journey

The purpose isn’t to impress; it’s to validate. A working slice of the product reveals assumptions that no amount of planning surfaces. “The API returns IDs, not slugs, so URL structure is different” is a two-hour fix in week three and a two-week refactor in week eight.

Ship the first deliverable with a short demo. Screen share, walk through what works and what’s still placeholder, and ask one question: “Does this match what you were expecting?”

The answer to that question is the most valuable feedback you’ll collect all month.

Week 4: Rhythm Established

By the end of month one, the project should have a cadence that can run on autopilot, the same steady rhythm covered in our sprint planning guide for client projects:

• Weekly sync: 30-45 minutes. What shipped last week, what’s planned this week, any blockers. The agenda is the same every week; it shouldn’t require preparation.
• Async updates: Short written update (Slack or email) on Friday afternoon. Three bullets: what shipped, what’s next, any decisions needed from the client. Takes 10 minutes to write and keeps the client informed without requiring a meeting.
• Running decision log: Shared doc that both sides update. The rule: any decision that would be inconvenient to revisit goes in the log.

The rhythm matters because it removes the question of “what’s happening?” from the client’s mind. They always know. That reduction in anxiety improves the relationship more than almost anything else.

Documentation You Create Upfront

The onboarding period should produce these artifacts before development is in full swing:

• Project brief (corrected and agreed on)
• Kickoff summary
• Architecture decision records for initial decisions
• Development environment README
• Glossary of terms (if the domain has jargon, and most do)

These aren’t deliverables to the client in the sense that the client asked for them. They’re the shared knowledge base that makes the engagement function. Teams that skip this documentation slow down every time a new person touches the project.

When Onboarding Goes Wrong

Some signals that the onboarding isn’t working:

The client stops responding to the weekly sync. Usually means they’ve lost confidence in the project. Don’t interpret this as being busy. Schedule a call specifically to ask if anything has changed since kickoff.

Scope discussions happen in Slack, not in writing. Scope changes that aren’t written down don’t exist as far as the project is concerned, and unwritten scope creep is exactly what our guide to protecting agency projects from scope creep is built to catch early. Pull every scope discussion into the decision log or a change request document.

You’re three weeks in and still waiting on access. Access delays are rarely about bureaucracy. They’re usually about uncertainty on the client’s side about what’s being built. Go back to the brief.

The client keeps bringing in new stakeholders. Every new person has opinions. This is normal, but it needs a defined process: new stakeholders review the brief and have 48 hours to raise concerns. After that, the project proceeds. This isn’t hostile; it’s how you protect the timeline, the same protection an SLA or support contract formalizes once the project moves past onboarding into ongoing work.

The One-Page Kickoff Document

After years of longer kickoff decks and briefing documents, we’ve simplified to a single page for most projects. It covers:

• The goal: One sentence. What are we building and why?
• Success criteria: Three things that would make this engagement successful
• Scope: What’s in this engagement, and explicitly what’s not
• Timeline: Key milestones and the date we’re working toward
• Contacts: Primary contact on each side with preferred communication channel
• Decision authority: Who can approve what without escalation

Keeping it to one page forces clarity. If you can’t summarize the project in one page, the project is not well-defined. That’s information you need before development starts, not after.

The first 30 days of an engagement feel slow compared to the alternative of just starting to build. But the alternative usually means spending the second 30 days untangling assumptions that should have been resolved in conversations. The investment is worth it every time.