Problem scene: interrupted 11 times a day, not a line of code written
Early on we took an e-commerce project with an eager client — daily LINE messages, three or four ad-hoc calls to confirm details. The result: engineers interrupted 11 times a day, 15–20 minutes to regain focus each time, under two hours of real coding a day. The project didn't go faster; it slipped, and the client felt "I said so much, why isn't it done." The problem wasn't diligence — it was using real-time communication for non-urgent things. From then on, we redesigned client communication as an async workflow.
What we do (What)
In one line: one fixed 30-minute sync meeting per week; everything else is async with a written trail.
The flow:
Daily needs/questions →(client) written into a Linear issue or a daily digest →(us) batch-replied at fixed times → if blocked, a Loom video explains it → one 30-minute weekly video call handles only "decide together" items → a written recap within 24 hours of the meeting.
Real-time calls are reserved for exactly one case: a production outage. Everything else is async.
Why we do it (Why)
Designing this, we traded between two things: response speed vs focus depth. Real-time comms get clients "replied instantly," at the cost of engineers never reaching deep work — and software quality depends heavily on uninterrupted focus. We chose to sacrifice some immediacy for less context-switching and fewer defects.
The other consideration is the paper trail. A requirement spoken on a call is remembered differently by both sides three weeks later — the seed of acceptance disputes. Putting all needs and decisions in writing means every decision is traceable. That actually protects the client — you won't hit "but I definitely said so" with no proof.
How we execute (How) — tools and files
- Requirements & tasks: Linear for issues, one card per need, transparent status. Clients get read-only access to progress anytime.
- Daily messages: Slack/LINE group, but with a rule: "non-urgent expects no instant reply"; we batch-process at two fixed windows daily.
- Complex explanations: Loom screen recordings — faster than typing to show "what this feature looks like."
- Weekly meeting: 30-minute video, fixed agenda template:
Weekly agenda (fixed 4 parts):
1. What shipped last week (3 min, against Linear)
2. This week's plan + decisions we need from you (10 min)
3. Blockers / risks / what we need from you (10 min)
4. Confirm next milestone and payment node (7 min)
Written recap sent within 24h.- Written recaps: Notion records decisions and action items with owners and dates.
The cost of this practice (honest)
- Clients used to instant replies need two weeks to adjust: we must proactively explain "why this is better for you"; some feel neglected at first.
- The urgent/non-urgent line needs constant calibration: occasionally a client feels something's urgent that we think can wait; "urgent" needs a clear definition.
- The writing cost isn't zero: recaps, Looms, Linear cards take time — an implicit cost we absorb, because we judge it cheaper than rework.
Where it doesn't fit
- Genuinely high-churn exploratory projects (still doing user interviews, changing direction daily) need tighter real-time collaboration; async cadence is too slow.
- No single point of contact on the client side: if you're dealing with five people who disagree, async becomes message chaos — converge the contact first.
Why clients should care
This directly shapes what you get:
- Steadier quality: uninterrupted engineers ship fewer bugs and less rework — your money goes to coding, not attention-switching.
- More transparent progress: you see every card's status in Linear anytime, no chasing.
- Fewer disputes: all needs and decisions are written, so acceptance has no "this isn't what I wanted / I definitely said so" ambiguity.
- Your time is respected too: 30 minutes once a week, no endless meetings and messages.
Advice for other teams
- Define "urgent" first: write it down (e.g. only production outages count), or everything becomes urgent.
- Meetings must have a fixed agenda template: an agenda-less meeting is the most divergent, wasteful kind.
- Send a written recap within 24 hours, always: this step is the foundation; skip it and async loses its "paper trail" value.
- Give clients a read-only progress board: transparency is the most effective way to reduce "chasing progress" messages.
Where we've actually used it (de-identified)
A restaurant-chain client cut ad-hoc messages by roughly 60% after adopting this, delivered on time, with zero acceptance disputes — because every need had a Linear card and every decision a recap. A startup client was the opposite: still changing product direction daily, so we proactively judged "you're not suited to pure async right now" and switched to two short meetings a week — an honest admission that this isn't a silver bullet.
FAQ
Only one meeting — won't I lose track of progress?
The opposite; you'll be clearer. You have read-only access to the Linear board and see every task card's status anytime, no waiting for meetings or chasing messages. The weekly meeting is for deciding together, not reporting progress — progress should be visible at all times.
What if something urgent comes up?
We keep a real-time channel for genuine emergencies (e.g. a site outage). The difference is we define "urgent" with you upfront, so not everything gets treated as urgent and drowns out the truly urgent.
How do you make sure you don't miss a requirement I raised?
Every requirement becomes a Linear issue with status and owner. Anything said verbally or in chat we convert into a card so you can see it. That's why we insist on a paper trail — a requirement not on the board is a requirement not yet accepted. Everything transparent.
Call to action
Want to work with a team that won't hostage you with meetings, yet keeps progress visible anytime? Or are you an engineer sick of all-day interruptions, looking to join a team that respects deep work? We'd like to talk to both.
- Email: [email protected]
- Phone: 0916-224-047
- LINE: @ufv9089p