You Have Too Many Tools (But Not the Ones You Think)

I audited a friend’s SaaS startup last month. Fifteen people, Series A funding, smart team. They’re paying for nine tools: Slack, Discord, Linear, Asana, Notion, Google Docs, Loom, Miro, and Calendly. Nine.

When I asked the ops person why they had both Slack and Discord, she said: “Slack is for work. Discord is for team culture.”

I asked if the team actually used Discord.

Silence.

Here’s the thing nobody tells you about tool stacks: the problem isn’t minimalism. The problem is that founders treat tool selection like a personality test — you either obsess over it like you’re picking a life partner or you sleepwalk through it and end up paying for Calendly until 2030. Meanwhile, the actual cost isn’t what you use. It’s what you pay for and forget exists.

You don’t need a 7-tool stack because 7 is a magic number. You need one because every tool beyond that is a barnacle on your hull — drag you don’t feel until you try to move fast. And nine times out of ten, you picked the wrong ones anyway.

The Actual Problem With Tools (Spoiler: It’s Not the Tools)

Most remote teams don’t fail because they have too many tools. They fail because they don’t commit to the ones they choose.

I’ve watched teams pick Asana, onboard for three weeks, then slowly defect back to spreadsheets because someone preferred the old workflow. Seen Slack instances where #general has 2,000 unread messages because nobody agreed on channel hygiene. Watched a 12-person company pay for Calendly when Google Calendar exists and is free.

The pattern is always the same: tools get added when someone has a problem. Nobody subtracts when the problem changes. And because most SaaS isn’t that expensive at first glance ($12 here, $20 there), it compounds silently until your monthly tool spend looks like a freelancer’s salary.

But the money isn’t actually the problem. The real cost is weirder than that.

Every tool you add creates a new decision: where does this information live? Is this a Notion thing or a Google Doc thing? Do I check Linear or Asana or both? Which Slack is the announcement in — work Slack or community Slack? This isn’t just context-switching. It’s decision fatigue before the workday even starts.

Slack’s research on this is worth reading. The average distributed worker checks 10+ tools per day. Not just opens them — actively checks them. That’s 10+ context loads per day, minimum. And that’s assuming you have discipline about which tools you use. (Most teams don’t.)

The Unofficial Rule I Actually Use

Here’s what I actually do when I advise teams on their stack: pick seven tools, max. Not because seven is magic. Because if you can’t fit your entire operation into seven tools, you have a process problem, not a tool problem.

That’s the real diagnostic. If you need Tool #8, the question isn’t “What tool solves this problem?” It’s “What process is broken that we think we need a new tool for?”

Most of the time, the answer is: something isn’t documented well enough, or nobody agreed on how information flows, or you’re treating a tool like a communication system when it’s actually a database.

But the constraint isn’t about being minimalist for minimalism’s sake. It’s about forcing you to choose. If you’re forced to choose between Linear and Asana, you’ll actually evaluate them instead of running both for six months like a couple that won’t break up. If you’re forced to choose between Slack and Discord, you’ll have a conversation about what each one is actually for.

That friction? That’s the point.

What Seven Actually Looks Like (And Why These Ones)

I’m going to walk through a stack that works for 15 people. It’s opinionated. It’s built around async as the default. It’s built around one principle: information should be easy to find and hard to lose.

1. Slack (Messaging, Real-Time Coordination)

If you’re under 10 people, this is optional. But at 15, you need some real-time coordination layer. Most teams choose Slack by default, and… it’s fine. It’s fine! Not a ringing endorsement, but I’m biased — I think Slack’s biggest feature is that everyone already knows how to use it.

Here’s what matters: treating it as async messaging, not real-time chat. Notifications off by default. “Do Not Disturb” from 6pm to 9am. Team norm is 24-hour response time, not 24-minute response time. Anything that requires immediacy (prod is down, security incident) is a phone call.

The free tier works fine until about 50 people. When you need full message history, the Pro plan at $12.50/user/month is worth it — but not before you need it.

One thing I’d change if I were optimizing: use channels for where information lives, not for where conversations happen. We created a #shipping channel where every single deploy gets logged. Not discussed. Logged. It’s a searchable record of what shipped when. Similar channels for #hiring, #decisions, #incidents. You read the channel to know what happened, not to participate in a conversation.

2. Linear (Engineering Tracking)

This one actually matters. Linear is built for async engineering work in a way that Asana and Monday.com simply aren’t. Issues link directly to pull requests. Comments live in the issue — not in a Slack thread that vanished three weeks ago like a sock in a dryer.

For 15 people, the free tier is a joke (10 issues max). The $10/user/month tier is a genuine upgrade and worth every penny.

Setup is straightforward: one project for product work, one for tech debt. Every issue gets an “outcome” field (what success looks like) and discussion happens in comments. Not meetings to “align on work.” Just documented async discussion.

The integration with Slack is native. When your #engineering channel is configured right, important Linear updates come to you — you don’t have to log in and check the dashboard multiple times a day.

3. Notion (Institutional Memory)

Notion is simultaneously the most underrated and overrated tool on this list. Most teams use it as a doc dump. “Here’s our employee handbook… company policies… that one thing nobody remembers.” And then nobody finds anything because there’s no structure.

But if you actually structure it, Notion becomes your team’s searchable institutional memory. Which matters more than you’d think at 15 people, because at 15 people, you’re starting to lose the “everyone knows everything” advantage you had at 5.

Create four sections: /handbook (roles, expectations, values), /onboarding (day 1 through day 30), /decisions (decision log), /templates (email templates, proposal templates, whatever your team needs).

The decision log is the one that actually changes how you operate. Every significant decision gets logged with context: what we decided, why, what alternatives we considered, trade-offs. It gets linked in Slack. It becomes searchable. Six months from now when someone asks “why do we do it this way?” you have the answer documented instead of reconstructing it from memory or finding whoever was in that meeting.

Notion’s pricing is confusing, but basically: free tier works for most operations under 15 people. Team plan at $10/user/month if you need version history and tighter permissions.

4. Loom (Async Video Explanation)

A 10-minute Loom beats a 90-minute meeting. Not sometimes. Almost always.

Product walkthrough? Loom. Onboarding for a new feature? Loom. Explaining why you made a technical decision? Loom.

The free tier has storage limits but works fine if you’re selective. $12.50/month for unlimited when you’re ready.

The moment you send your first Loom instead of scheduling a 30-minute synchronous meeting, you will realize how much of your past meeting life was theater. People pause, rewind, take notes. They don’t multitask. The medium forces engagement that live meetings almost never do. (I started replacing my weekly updates with Looms and the feedback was immediate — people actually retained what I said. Turns out 8 minutes of focused attention beats 45 minutes of half-listening.)

5. Google Sheets (Dashboards and Tracking)

This one feels boring and obvious and it’s actually the most valuable tool in the stack.

Create one shared dashboard. MRR if you’re a subscription business, hiring pipeline status, feature rollout progress, bug count, whatever your business actually cares about. Update it daily. Share the link in #general. Everyone sees the same number at the same time.

This replaces: weekly business review meetings, status update presentations, “I wonder how we’re doing” Slack questions.

And because it’s Google Sheets, someone can embed it on a dashboard in Notion if they want to. You’re not locked into viewing it in a specific way.

Free if you have Google Workspace. Otherwise, free Google account.

6. GitHub (Code and Changelog)

If your team writes code, this is non-negotiable. And the key here is using it for the things GitHub is actually good at instead of trying to make it your project management system.

Pull requests are async code review. Use them. Reviewers comment async. Merges can wait 24 hours. There’s no such thing as a “let’s sync on the PR” meeting — it’s written in the diff.

The releases page becomes your changelog. If you automate it from commit messages (most modern teams do), you get a searchable record of what shipped when and why.

Free for public repos. $21/month for private repos per user — which sounds weird but is actually reasonable if you have a team using it.

7. Typefully (Social Scheduling)

This one is last because it’s the most optional. If you don’t do social content distribution, skip it.

But if you do — if you’re publishing a newsletter or doing social posting regularly — Typefully saves you from the chaos of “when do we actually post this?” It’s a calendar view, draft-review-schedule workflow, and it integrates with Twitter and LinkedIn.

$20/month for the real plan. Worth it if you’re shipping social content more than once a month.

Why I Didn’t Include These

Asana, Monday.com, Jira. — If Linear doesn’t work for your team, you have a different problem. These tools are trying to be everything, which means they’re mediocre at the core thing: async engineering work. I’ve talked to teams who love Asana. They also pay for it and don’t use it. That’s a different category of mistake.

Discord. — Slack does this. You don’t need both. I get the cultural difference argument. What I don’t get is maintaining two platforms for it. That’s just context-switching with extra steps.

Calendly. — Google Calendar has a “available time” feature. It’s less polished than Calendly, but it’s free and it eliminates the app switch. If you’re booking 40+ meetings a month, Calendly’s interface is objectively better. Before that, it’s overhead.

Zapier or Make (formerly Integromat). — I have a soft spot for automation tools. I really do. But they’re technical debt wearing a productivity costume. They feel like problem-solving (automate the repetitive stuff!) but what you’re actually building is a Rube Goldberg machine that depends on three different companies’ APIs not breaking simultaneously. If you find yourself reaching for Zapier, the real question is: should this integration exist, or should these two tools be talking natively?

The pattern here: each one I excluded seems like it fills a gap. It doesn’t. It’s usually a sign that something in your process is broken and you’re trying to tool your way past it.

The Real Cost: It’s Not the Monthly Fee

Here’s what changes when you’re ruthless about your stack.

First, onboarding becomes simpler. New hire learns one tool for code, one for docs, one for messaging. Not four different project management systems and three different docs platforms.

Second, you stop bleeding money on things you forgot existed. That Calendly seat you’re still paying for in month seven because somebody set it up? It disappears.

Third — and this one’s more subtle — you actually commit to using your tools well instead of surface-level using eight tools poorly. When you have seven, you have to make each one work. You configure channels correctly in Slack. You write clear issue descriptions in Linear. You structure your Notion pages. You don’t get the luxury of “well, this tool isn’t quite right, let me add a new one.”

That’s where the actual productivity gains come from. Not from picking the perfect tools. From committing to good tools and using them right.

Try This

Open your stack right now. Write down every tool you’re paying for. Don’t estimate. Actually log in to your billing dashboard and list them.

Next to each one, write down the last time someone actually used it.

Be honest. Not “someone probably used it” — when did you personally see it being used? When was the last meaningful interaction?

Now count how many you could delete today without anyone noticing.

That number is your real problem.

---

Worth Your Time

On tool fatigue: Slack published a study on context-switching costs that I keep going back to. Not the “15 minutes to refocus” claim — I’m skeptical of that specific number. But their breakdown of how distributed teams actually behave when they’re overloaded with tools is uncomfortably accurate. Spoiler: nobody’s using the tools the way the tool was designed. Check it out here.

On Linear vs. everything else: Linear’s blog has a genuinely smart walkthrough of how async issue management changes engineering culture. I don’t agree with all of it — they oversell their own product, obviously — but the underlying argument about why project tracking should be async-native is something I haven’t seen articulated better anywhere else.

On decision logs: GitLab’s public handbook remains the gold standard for documentation-as-infrastructure. Their decision logging section is useful even if your team is 1/100th their size. I’ve adapted their format for teams of 12 and it still works. The principle is what matters, not the scale.

On the human cost: Amir Salihefendic (Doist CEO) has a post about async work and loneliness that I think about more than I’d like to admit. Tools scale work. They don’t scale belonging. That gap is the thing that keeps me up at night about this whole approach, if I’m being honest. Check out our breakdown of remote-first tool strategies for more on how companies are rethinking their operational stack.

---

Your second hire will tell you if your stack is broken. By hire seven, you’ve either fixed it or you’re swimming in tool debt. By fifteen… well, you already know how that story ends. Nine tools, four of them actually used, and a monthly invoice that makes you wince.

Seven isn’t the magic number. Choosing is.