We have engineers in Canada, Pakistan, Ukraine, Nigeria, Brazil, India, the Philippines, and Germany. Our timezone spread is thirteen hours. We ship every week, and we do it with two recurring meetings on the entire calendar. This is not an accident or a perk. Async-first is a deliberate operating system, and it is one of the main reasons a small senior-only team can outpace agencies several times our size.
The meeting tax
Every sixty-minute meeting with five people costs five engineer-hours. That is half a day of productive output gone before anyone writes a line of code. Multiply that across daily standups, weekly syncs, planning sessions, and the endless ad-hoc calls that fill a calendar, and most teams that call themselves agile are spending 20 to 30 percent of their working hours talking about work instead of doing it.
Async-first does not mean no communication. It means defaulting to written, recorded, and permanent communication over synchronous calls. It means trusting engineers to manage their own time and judging them on what they ship, not on whether they were visibly online at 9am in a timezone that has nothing to do with the work.
Written by default
The core habit is simple: if something matters, write it down where the next person can find it. A decision made in a call that is not written down did not really happen, because in two weeks nobody will remember the reasoning and someone will relitigate it. A decision captured in a document compounds. It onboards the next engineer, settles the next debate, and survives the people who made it.
This discipline is what lets us promise a first commit within 48 hours of kickoff. There is no tribal knowledge locked in someone's head and no meeting required to unlock it. The context lives in the repository and the spec, where any senior engineer can absorb it and start shipping.
Our stack
Notion holds a living spec for every project. Not a PDF that is out of date by Tuesday, but a real document that engineers update as they discover things.
Linear holds all tasks, priorities, and status in one place, so nobody has to send a Slack message asking what the status of something is.
Loom covers anything that takes twenty minutes to write but three minutes to show: pull request walkthroughs, bug reproductions, and architecture reviews.
GitHub treats pull request descriptions as first-class documents. Every PR carries a summary, screenshots, test coverage, and a deployment checklist, so review can happen whenever the reviewer is awake.
The rule we live by
If a question can be answered by reading existing documentation, it should not be asked in chat. If it cannot, that is a documentation gap, not a meeting opportunity. Write the answer down and improve the docs so the question never has to be asked again. Over months this turns a project into a system that explains itself, which is exactly what you want when your team spans thirteen hours of daylight.
When we do meet
We keep exactly two recurring meetings. The first is a weekly thirty-minute demo with the client, recorded so anyone who could not attend can watch it later. The second is a fortnightly retrospective. Everything else is asynchronous. When a real-time conversation is genuinely the fastest path, we have it, record it, and transcribe it automatically so the outcome rejoins the written record.
Why clients feel the difference
For a client, async-first shows up as a progress update every morning regardless of where their team sits. The engineers building a microservices analytics platform in Singapore did not need a daily call with stakeholders to stay aligned, because the written trail did that job continuously. You see commits, deployed previews, and a short written summary of what moved and what is next. That visibility is usually better than what an in-house team provides, precisely because we are forced to make our work legible.
It also keeps us honest on billing
Async-first pairs naturally with how we charge. Because the work is visible and the deliverables are written down, there is no ambiguity about what was done. That is the foundation of our milestone-based pricing: you can see the shipped result before you pay for it, instead of trusting a timesheet.
The failure mode to avoid
Async-first has one classic way of going wrong: writing that nobody reads, or status updates that exist to perform activity rather than to inform. The fix is not more documentation, it is better-targeted documentation. A good async update answers three things in a few lines: what shipped, what is blocked, and what is next. Anything longer usually means the writer has not done the thinking yet. We coach engineers to write the summary first and the detail underneath, so a busy reader gets the signal in ten seconds and the depth only if they need it. Async only saves time if the reading is faster than the meeting it replaced.
Is async-first for everyone?
No. It demands strong writers, high trust, and engineers who are genuinely senior enough to make decisions without a meeting to hide behind. A team built on juniors cannot run this way, which is part of why our model and our hiring bar reinforce each other. If you are building a product and want a team that communicates in artifacts you can actually read rather than meetings you have to attend, start a conversation with us.