The First 90 Days With a New Agency Client: A Delivery Playbook

The contract is signed, the deposit cleared, and the kickoff call is on Thursday. Most agencies treat this moment as the finish line of sales when it's actually the riskiest 90 days of the entire engagement. Mess up the early choreography and you'll be fighting scope creep, surprise stakeholders, and "why is this taking so long" emails by week six.

This is the playbook we use at 72Technologies for new client engagements, refined across enough projects to know what breaks. It's biased toward custom software work — web, mobile, e-commerce — but the structure holds for most agency contexts.

Why the First 90 Days Decide the Outcome

Clients form their lasting opinion of your agency in the first six weeks. After that, the narrative is largely fixed: you're either "the team that gets it" or "the team we have to manage." Recovering from the second label is expensive and sometimes impossible.

The technical work isn't the hard part. The hard part is calibrating four things simultaneously:

• Decision-making: who actually says yes, and how fast
• Scope shape: what the client thinks they bought vs. what's in the SOW
• Communication rhythm: how often, what format, who attends
• Trust currency: small visible wins that buy you credibility for the harder months ahead

If you only optimise for shipping code, you'll have a great burndown chart and an unhappy client. We've done that. It doesn't end well.

Days 1 – 14: Kickoff, Access, and the Stakeholder Map

The first two weeks are administrative on paper and political in practice. The goal isn't to start coding — it's to remove every excuse you might have in month two for missing a deadline.

The kickoff call we actually run

Forget the 90-minute "introduce everyone" theatre. We run a 60-minute kickoff with a tight agenda:

1. Restate the goal of the engagement in one sentence. Get the client to nod or correct it.
2. Confirm the decision-maker. Not "the team" — one human whose Slack message ends an argument.
3. Walk through the SOW's in-scope and out-of-scope lists out loud. This is uncomfortable. Do it anyway.
4. Agree the demo cadence (we default to every two weeks, Thursday afternoons).
5. Identify the top three risks the client sees. Write them down. Reference them later.

The out-of-scope read-through is the single highest-leverage thing on this list. If a client is going to push back on the boundaries, you want it to happen now, with the deposit fresh in your account, not in week eight.

Access checklist

Nothing kills momentum like waiting on a SAML invite. By end of week one we want:

[ ] Source control org access (with our standard branch protection)
[ ] Cloud account / IAM roles
[ ] Staging domain delegated or CNAME plan agreed
[ ] Design tool access (Figma viewer minimum)
[ ] Analytics, error tracking, and existing logs read access
[ ] Shared Slack/Teams channel with the right humans
[ ] Calendar holds for demo cadence through month three

If any of these aren't done by day ten, that's a flag — not because the items matter individually, but because slow access usually predicts slow decisions later.

Days 15 – 30: The Smallest Real Thing

Week three is when most agencies disappear into a "discovery phase" and resurface a month later with a Miro board. Don't do that. Ship something small and real by day 30, even if the architecture isn't final.

It doesn't have to be production. It has to be:

• Deployed somewhere the client can click
• End-to-end through at least one real flow (auth → one core action → persisted result)
• Theirs — running in their cloud account or on their domain

This does three things at once. It proves the team can ship, it surfaces integration surprises early (SSO quirks, weird DNS, a legacy API that returns XML), and it gives the client something tangible to show their own stakeholders. That last part matters more than engineers think. Your client has a boss too.

A note on the "discovery is essential" objection

Discovery is essential. It just doesn't have to block delivery. Run them in parallel: a senior engineer and a designer can produce a thin vertical slice while the rest of the team interviews users and shapes the longer roadmap. We've written more about how we scope projects without burning a month on slide decks.

Days 31 – 60: Rhythm, Not Heroics

Month two is where the engagement either becomes boringly predictable — which is what you want — or starts to wobble. The deciding factor is rhythm.

The demo is the contract

Every two weeks, on the same day, at the same time, the client sees working software. Not screenshots. Not a status doc. The actual product, driven live by an engineer or PM who can answer questions.

What the demo accomplishes that no status report can:

• Forces the team to finish things, not just start them
• Gives the client a low-stakes channel to redirect early
• Builds a shared visual memory of progress (critical for the inevitable "what have you been doing?" moment in month four)
• Surfaces scope drift before it becomes a change order fight

We run demos in roughly this shape:

5 min  - What we said we'd ship this sprint
20 min - Live walkthrough of what actually shipped
10 min - What's planned for next sprint + any tradeoffs
10 min - Open questions / decisions needed from client
5 min  - Risks and asks

If a sprint produced nothing demo-able, you don't cancel the demo. You show up and explain why. That conversation is uncomfortable exactly once.

Scope conversations, not scope battles

New requests will arrive. They always do. The framing that's worked for us: never say no, always show the tradeoff.

"Happy to add the bulk import feature. To keep the launch date, we'd defer the admin audit log to phase two — or we can keep both in and move launch by about three weeks. Which works better for you?"

This isn't a script trick. It's the truth, surfaced early, with the decision handed back to the person who's actually paying. Clients who feel in control of tradeoffs rarely escalate.

Days 61 – 90: The Trust Audit

Month three is when you find out whether the first two months actually worked. The signal isn't whether the client is happy — clients are usually polite. The signal is whether they're delegating.

Good signs around day 75:

• The client stops attending every standup and trusts the recap
• They start forwarding internal questions to your team directly
• New work appears in conversation before it appears in an email demanding estimates
• Their finance team pays invoices without a back-and-forth

Bad signs:

• CC lists on emails keep growing
• You're being asked to justify hours rather than outcomes
• Demos are getting rescheduled by the client
• Someone new shows up in week ten with "a few questions about the approach"

That last one is the killer. A new stakeholder appearing late means the original sponsor didn't have the authority you assumed, or didn't socialise the project internally. Either way, you now have a second sales cycle to run with someone who wasn't in the room for the SOW.

The 90-day review

Around day 85, we run an explicit checkpoint with the client. Not a status meeting — a review. We bring:

• What we committed to in the SOW vs. what's shipped
• What changed and why (with the tradeoff conversations referenced)
• A frank assessment of what's working in the collaboration and what isn't
• A proposed shape for the next quarter, including team composition

This is also where we'd renegotiate the engagement model if needed — moving from fixed-bid to a capped retainer, or adjusting the team mix. Doing it at a defined checkpoint feels professional. Doing it reactively in month five feels like you're in trouble.

Where We'd Start

If you're inheriting a messy onboarding process at your agency, don't try to fix all of this at once. Pick two things for the next engagement: a real kickoff agenda with the out-of-scope read-through, and a fixed demo cadence with a published format. Those two alone will change how month three feels.

Everything else — access checklists, the day-30 vertical slice, the 90-day review — is incremental polish on top. The core idea is simpler than the playbook makes it look: ship something visible quickly, talk about tradeoffs honestly, and treat the first 90 days as a relationship being built rather than a project being executed. The teams that internalise that don't need playbooks. The rest of us write them down.