Every remote team has a graveyard of tools that looked great in a demo and died within a quarter. Ours is no exception. After three years of running distributed product teams across four time zones, this is the short list that survived — and the reasoning behind each pick.
One principle: fewer places to look
Every tool we add is another inbox. The question we ask before adopting anything is not "is this good?" but "what does this let us delete?" A tool that adds a notification channel without removing one is a net loss, no matter how polished it is.
Async first: written decisions
Decisions live in written documents, not meeting memories. We keep one doc per initiative with a decision log at the top. Anyone can read the reasoning six months later without asking the person who made the call — who may have left, or may simply not remember.
- Linear for issues — fast, opinionated, and it never lets a ticket sit without an owner.
- Notion for specs and decision logs — one page per initiative, decisions pinned at the top.
- Loom for walkthroughs — a five-minute recording replaces a thirty-minute meeting nine times out of ten.
- GitHub with required reviews — code review is where most of our real design conversation happens.
Sync sparingly: two rituals
We run exactly two recurring meetings per team. A weekly demo where working software is shown, never slides. And a fortnightly retro where the only agenda is what slowed us down. Everything else is opt-in and has a written agenda before the invite goes out.
If it cannot be demonstrated, it did not happen this week.
What we dropped
Daily standups were the first to go — they became status theatre. Slack threads for decisions were next; they are unsearchable a month later. And we stopped using a separate wiki, because a wiki nobody edits is worse than no wiki at all.
The stack is deliberately boring. Boring tools have stable APIs, predictable pricing, and no surprise redesigns. That leaves our attention for the work that actually matters: shipping the product.
