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, we have a short list of remote collaboration tools that survived — and, more usefully, a set of rules for deciding what gets to join it.
This is the stack we run for our own engineering work and set up for founders we partner with. It is deliberately small. Below you will find the principle behind it, each tool and the job it does, the two meetings we keep, what we dropped, and how to choose your own stack without collecting subscriptions.
The one principle behind our remote collaboration tools
Every tool we add is another place to look. 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.
That principle sounds austere, but it is what makes distributed work feel calm instead of frantic. When there is exactly one place for tasks, one place for decisions and one place for code discussion, nobody has to ask where something lives. New people get productive faster, and the question "did you see my message?" mostly disappears.
Async first: written decisions
Remote teams live or die on writing. Decisions live in documents, not in meeting memories. We keep one document per initiative with a decision log pinned at the top: what we decided, when, who decided it and why. 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.
For architecture choices we use a lightweight version of architecture decision records: a short page with the context, the options considered and the consequences we accepted. It takes ten minutes to write and saves hours of re-litigating the same question every time someone new joins.
GitLab's public guide to all-remote work makes the same point at a much larger scale: write things down by default, and treat the written source as the truth. You do not need a thousand-page handbook to benefit from that habit. You need one page per decision, kept where people already look.
The stack: one tool per job
Here is the full list, and the single job each tool is allowed to do. If a tool starts doing two jobs, one of them usually moves elsewhere.
| Job | Tool we use | Why it earned its place |
|---|---|---|
| Issues and planning | Linear | Fast, opinionated, and it never lets a ticket sit without an owner. |
| Specs and decision logs | Notion | One page per initiative, decisions pinned at the top, easy to link. |
| Async walkthroughs | Loom | A five-minute recording replaces most thirty-minute meetings. |
| Code and review | GitHub | Required reviews — where most of our real design conversation happens. |
| Design | Figma | Designers and engineers comment on the same frames, not on screenshots. |
| Quick questions | Slack | Short-lived chat only. Anything that matters gets written up elsewhere. |
Issues: Linear
Issue trackers are where remote teams quietly lose weeks. We like Linear because it is fast enough that people actually update it, and its defaults push every ticket toward an owner and a cycle. The rule on top: if work is not in the tracker, it is not happening.
Specs and decisions: Notion
Every initiative gets a page with the problem, the proposed approach, open questions and the decision log. Engineers link the page from their pull requests, so the "why" travels with the code. We keep the structure boring on purpose — the same headings every time — so nobody has to learn a new format.
Async video: Loom
A short screen recording is the most underrated of all remote collaboration tools. A walkthrough of a new feature, a bug reproduction or a design review can be watched at 1.5× by everyone in their own time zone. The recording links back to the document it relates to, so it never becomes an orphan.
Code review: GitHub
We require at least one review on every change. Review is not just a quality gate; it is where engineers across time zones discuss trade-offs in writing, attached to the exact lines they affect. If you are building a product and want to know how we structure engineering day to day, our software development service runs exactly this way.
Design: Figma, tied to a system
Design files work remotely only when they point at a shared set of components. Otherwise every handoff becomes a debate about spacing. We covered how to set that up in Design Systems 101.
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.
The weekly demo does more for alignment than any status report. Founders see real progress, engineers get direct feedback, and problems surface while they are still cheap. Basecamp's Shape Up method takes a similar view: fixed time, variable scope, and showing work rather than reporting on it.
What we dropped
Daily standups were the first to go — they became status theatre. A written check-in in the tracker gives the same information without pulling six people into a call across time zones. 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.
- Daily standups → replaced by async updates on the ticket itself.
- Decisions in chat → replaced by the decision log on the initiative page.
- A standalone wiki → folded into the same docs tool the team already opens every day.
- Overlapping trackers → one tracker, no side spreadsheets.
How to choose remote collaboration tools for your team
If you are setting up a remote team for the first time, resist the urge to adopt everything at once. Start with the jobs, not the brands. Use this order:
- Write down the jobs. Tasks, decisions, code discussion, design feedback and quick questions cover most product teams.
- Assign one tool per job. If two tools do the same job, pick one and delete the other within the month.
- Set the rules before the tool. Where do decisions live? What counts as urgent? What response time is normal across time zones?
- Prefer what the team already knows. A familiar tool used well beats a better tool nobody adopts.
- Review quarterly. In a retro, ask which tool you would miss least. Remove it and see if anyone notices.
Pricing matters less than people expect at startup scale; attention matters more. The real cost of a tool is the hours spent checking it, syncing it with other tools and teaching it to new hires.
A starter stack for a new founding team
For a founder with two to five engineers, the minimum viable set of remote collaboration tools is short: an issue tracker, a docs tool with a decision-log template, a code host with required reviews, and a chat tool with a written rule that decisions do not live there. Add async video and design tooling when you have designers and more than one time zone.
The stack is deliberately boring. Boring tools have stable APIs, predictable pricing and no surprise redesigns. That leaves attention for the work that matters: shipping the product.
If you are building a distributed product team and want a senior partner to set up how it works — tools, rituals and engineering standards — that is part of our technology consulting work. Tell us what you are building and a senior engineer will reply within one business day.
Frequently asked questions
What are the best remote collaboration tools for a small team?
For most small product teams: an issue tracker such as Linear, a docs tool such as Notion for specs and decisions, GitHub for code and reviews, Loom for async walkthroughs, Figma for design and Slack for quick questions. The right set is the smallest one that gives every job exactly one home.
How many collaboration tools does a remote team need?
Usually five or six — one per job: tasks, decisions, code, design, async video and chat. More than that and people start asking where things live; fewer and one tool ends up doing two jobs badly.
Should remote teams make decisions in Slack?
No. Chat is fine for quick questions, but decisions made in threads are hard to find a month later. Record every decision in a written log on the relevant document, and link to it from chat if needed.
Do remote teams still need daily standups?
Rarely. Across time zones, a daily call tends to become status theatre. Async updates on each ticket plus a weekly demo of working software give founders better visibility with far less meeting time.
How often should you review your remote tool stack?
Once a quarter, in a retro. Ask which tool the team would miss least, remove it, and see whether anyone notices. Tools accumulate quietly; removing them has to be deliberate.
