The Client Who Won't Decide: A Playbook for Unblocking Non-Technical Stakeholders

Most agency projects don't die because the engineering is hard. They die because someone on the client side won't make a call, and the sprint bleeds out waiting. If you've ever watched a two-week sprint turn into six because "Marcus is still thinking about the onboarding flow," this one's for you.

The real cost of an undecided client

When a non-technical client can't commit to a decision, the damage compounds in ways your Gantt chart doesn't show:

• Engineers context-switch to unblocked tickets, then context-switch back a week later and lose half a day rebuilding mental state.
• Half-built features sit in feature branches, quietly rotting against main.
• Your PM burns hours writing follow-up emails that should have taken one Slack message.
• The client, ironically, starts feeling like you're slow.

In our experience running fixed-scope builds, roughly a third of overruns trace back to decision latency, not estimation error. That's a process problem, and process problems have process fixes.

Why smart clients freeze

Before we get to tactics, understand the shape of the problem. Non-technical stakeholders freeze for predictable reasons:

1. They don't understand the trade-off. You asked "Postgres or DynamoDB?" — they heard "pick your favourite colour, but wrong answers cost $40k."
2. They're waiting for someone else. Usually a co-founder, an investor, or a customer they haven't actually asked yet.
3. They're conflating reversible and irreversible decisions. Every choice feels like a one-way door.
4. They don't know they're the decider. They assume you'll figure it out, and you assume they'll tell you.

Each of these has a different fix. Lumping them together as "the client is slow" is how you end up rewriting the same email three times.

Frame every decision as a two-option trade-off

The single highest-leverage change we made in the last few years: stop asking open questions. Never send a client "What do you want the dashboard to look like?" Send them two options with the consequences spelled out.

Here's the template we use, dropped straight into Linear or Notion:

**Decision needed:** Dashboard default view
**Deadline:** Thu 14 Nov, 5pm (blocks sprint 12)
**Decider:** Sarah

**Option A — Activity feed first**
- Cost: ~2 days
- Users see recent events on load
- Better for daily-return users
- Trade-off: new users see an empty state

**Option B — Setup checklist first**
- Cost: ~3 days
- New users get a guided path
- Trade-off: returning users see "done" tick-boxes they don't need

**Our recommendation:** B, because your current activation rate is the bigger problem.
**If no reply by deadline:** we proceed with B.

Three things are doing work here. First, it's binary — humans decide between two things far faster than between five. Second, the deadline and default make silence a decision, not a delay. Third, the recommendation removes the "I don't know enough to choose" excuse, because now the client is either agreeing with an expert or explicitly overriding one. Both are easy.

The recommendation matters more than you think

Junior PMs avoid recommendations because they don't want to "push the client." This is backwards. Clients hired you for judgement. Withholding it to seem neutral is a form of cowardice dressed up as respect. Say what you'd do, then let them override you.

Separate one-way doors from two-way doors

Jeff Bezos' framing is old but underused in agency work. Most decisions on a build are reversible — button colour, copy, even API shape if you're careful with versioning. A few are not: your primary datastore, your auth provider, your billing model, your framework choice.

At kickoff, we write two lists together with the client:

• One-way doors (5 – 8 items, decided in week one, thought about carefully)
• Two-way doors (everything else, decided fast, reversed if wrong)

Then we tell the client explicitly: on two-way doors, we will make the call and tell you afterwards unless you object within 48 hours. This one sentence, agreed in writing at kickoff, saves us weeks per project. It gives permission to move on the 80% of decisions that don't warrant a meeting.

Run a weekly decision review, not a status meeting

Status meetings are the worst forum ever invented for making decisions. Everyone's half-listening, the client feels obliged to fill silence with new ideas, and nothing gets written down properly.

Replace your weekly status call with a decision review. The agenda is fixed:

1. Decisions made last week (2 minutes — recap, no debate)
2. Decisions needed this week (bulk of the meeting)
3. Decisions coming up in the next 2 – 3 weeks (heads-up only)

Status goes in a written update sent 24 hours before the meeting. If the client hasn't read it, reschedule. This sounds harsh; it isn't. It's the same discipline you'd apply to a code review.

The decision log is the artefact

Every decision — who made it, when, and the alternatives considered — goes in a single append-only doc. Not Slack, not email, not the Notion page nobody remembers. One log. When a stakeholder shows up in month four and says "why did we build it this way?", you paste the entry. Arguments end in seconds instead of days.

We format ours like this:

## 2026-01-14 — Use Stripe Checkout instead of custom flow
**Decider:** Sarah (CEO)
**Options considered:** Stripe Checkout, custom Elements flow, Paddle
**Chose:** Stripe Checkout
**Why:** Ship 3 weeks faster, acceptable trade-off on branding for MVP
**Reversible?** Yes — can migrate to Elements post-launch
**Related tickets:** BILL-42, BILL-43

This is boring. That's the point. Boring processes survive founder chaos.

Identify the actual decider on day one

On every project, ask this question in the kickoff meeting and don't move on until you have an answer: "For each of these areas — product, design, technical architecture, budget — who has the final say?"

You will get vague answers. Push. "We decide together as a team" means nothing ships. Someone has to own it. If the client insists on committee decisions, insist on a named tiebreaker for each area. Write those names into the SoW.

Also ask: "Is there anyone not in this room whose approval you'll need?" This uncovers the invisible investor, the co-founder in another country, the compliance officer, the parent-company legal team. Every one of them is a decision-latency landmine you'd rather find in week one than week seven.

When the client still won't decide

Sometimes you do all this and the client still stalls. Here's the escalation ladder we use, in order:

1. Restate the cost in their currency. Not "this blocks the sprint" — "this pushes launch past your investor demo."
2. Offer to decide for them, in writing. "If we don't hear back by Friday, we'll ship Option B. Reply 'stop' to override." Nine times out of ten, this unblocks them within an hour.
3. Schedule a 20-minute decision call. Not a status call. Camera on, one topic, one outcome. Send the two-option doc beforehand.
4. Escalate to the money. If the CEO isn't the decider but is paying the bill, loop them in with a factual note about timeline risk. Do this sparingly — it burns political capital — but do it before the project misses a milestone, not after.

If you're getting to step 4 more than once per project, you have a client-fit problem, not a process problem. Some clients simply cannot make decisions at the pace a fixed-scope build requires. Better to spot this in week two and renegotiate to time-and-materials than to eat the overrun.

Where we'd start

If you take one thing from this: rewrite your next client email as a two-option decision with a recommendation and a deadline. Just one. See how fast the reply comes back. If it works — and it will — build the rest of the scaffolding around it: the decision log, the named deciders, the one-way/two-way split at kickoff.

Process for its own sake is bureaucracy. Process that turns three-day silences into three-minute Slack replies is leverage. If you want to see how we structure this into fixed-scope engagements, the services page has more, or dig around the blog for the pricing and scoping pieces that pair with this one.