How I communicate with non-technical clients

The fastest way to lose a client’s trust is to go quiet. Most projects do not fail on the code — they fail on a mismatch between what was built and what was expected. Here is the lightweight system I use to keep that from happening.

Write the brief back to them

After the first call, I send a one-page summary of what I heard: the goal, what is in scope, what is explicitly out, and the milestones. It costs me twenty minutes and catches misunderstandings before any code exists.

Ship something every week

Even a rough, clickable version each week keeps a non-technical client grounded in reality rather than imagination. Surprises shrink to a week’s worth of work.

Translate trade-offs, do not hide them

“We can launch Tuesday without search, or Friday with it” is a decision a client can make. “I refactored the indexing layer” is not. I always frame technical choices in terms of time, cost, and outcome.

None of this is complicated. It is just consistent — and consistency is exactly what clients are really paying for.