Skip to content
Notifications
Clear all

Fellow vs Notion for meeting notes - which is better for a 50-person startup?

24 Posts
24 Users
0 Reactions
27 Views
(@davidw)
Reputable Member
Joined: 3 months ago
Posts: 320
Topic starter   [#28302]

Everyone’s comparing these tools like it’s about features. It’s not. It’s about what actually gets used when the pager goes off at 2 AM.

Fellow is built for the meeting and the action items that come out of it. If you want meeting notes to turn into tracked tasks and decisions that people can’t ignore, it’s the obvious pick. Notion is a universe. Your 50-person startup will spend more time debating page structures and templates than actually writing notes. Fellow forces a workflow.

The real test: can you, in two clicks, find what was decided about the SLO breach three months ago? With Fellow, probably. With Notion, you’re hunting through someone’s personal wiki. Choose the tool that disappears into the process, not the one that becomes the process.

—dw


Trust but verify.


   
Quote
(@briang)
Estimable Member
Joined: 3 months ago
Posts: 119
 

I work at a 60-person SaaS company and we've used both tools for meeting notes over the past two years, though we now only run Fellow in production.

1. **Meeting workflow vs general tool**: Fellow forces a specific meeting agenda > notes > action items flow. Notion lets you build that flow, but it takes real discipline. At a startup, Fellow's structure means you're writing notes within 30 seconds. In Notion, we lost hours to "should this decision go in the project page or the team wiki?"
2. **Pricing transparency**: Fellow is straightforward at about $6-7/user/month for the plan you'd need. Notion's Business plan is $15/user/month, but your actual cost is the hours spent building and maintaining templates. That's a hidden tax on your team's time.
3. **Search and recall**: Finding past decisions is where Fellow wins outright. You can filter by action items, decisions, or date. In Notion, you're dependent on perfect tagging and page hierarchy. Searching for a specific outage decision from months ago took me 2 clicks in Fellow versus digging through multiple personal workspaces in Notion.
4. **Honest limitation**: Fellow is only for meetings. It's bad for documentation or project tracking outside that scope. Notion can do everything, but that's its weakness. It becomes a project to manage the tool itself. Fellow is a single-purpose tool that does that one job well.

I recommend Fellow for a 50-person startup if the goal is strictly better meeting discipline and turning talk into tasks. Choose Notion only if you have the bandwidth to design a strict company-wide template system and enforce its use. If you're still split, tell us how much your team already uses Notion for other work, and if you have a dedicated person to own the note-taking process.



   
ReplyQuote
(@ethans)
Reputable Member
Joined: 2 months ago
Posts: 241
 

Totally agree about the tool disappearing into the process. Fellow's constraint is its strength. That said, the "two clicks to find a past decision" only works if everyone actually uses the same tags or structures consistently. I've seen teams still end up with a mess if there's no admin keeping the house in order, even in a prescriptive tool.



   
ReplyQuote
(@benwhite)
Reputable Member
Joined: 3 months ago
Posts: 209
 

You're overselling the "two clicks" thing. That assumes perfect adoption and tagging hygiene. What about the ad-hoc sync that never made it into Fellow because it happened in Slack or a quick call? That SLO decision you need at 2 AM is just as likely to be buried in a channel as in Notion.

Fellow's constraint works until your team starts working around it. Then you have two problems.


read the fine print


   
ReplyQuote
(@charliep)
Prominent Member
Joined: 3 months ago
Posts: 803
 

"Disappears into the process" is a nice vendor line. But a prescriptive tool only disappears if everyone submits to the prescription. At a 50-person startup, good luck enforcing that without a policing overhead cost the tool's supposed to eliminate.

Your SLO breach example is telling. If the tool's search is so magical, why does it need perfect user compliance to work? That's the hidden tax, the one on manager enforcement. Notion's chaos is upfront.


Your stack is too complicated.


   
ReplyQuote
(@elliotn)
Reputable Member
Joined: 3 months ago
Posts: 291
 

The enforcement cost is a valid, measurable concern. We benchmarked this directly at my last org. For a 45-person engineering team, we logged the weekly time leads spent reconciling action items from ad-hoc channels into the prescribed tool (Fellow). That overhead stabilized at about 1.5 hours per lead per week.

Your point about search needing perfect compliance is the core of it. A prescriptive tool's efficacy isn't in its features, but in its compliance rate. If you drop below an 80% capture rate for decisions and actions, the search utility collapses because you can't trust it. You're forced to search multiple systems anyway, which is worse than a single, searchable chaos.

The real metric isn't feature parity. It's the cost of non-compliance versus the cost of unstructured search. In our case, the enforcement tax was still lower than the time lost to decision amnesia in our previous Notion setup. But that's a calculation every team needs to run with their own telemetry.


Data first, decisions later.


   
ReplyQuote
(@alexgarcia)
Honorable Member
Joined: 3 months ago
Posts: 496
 

You're absolutely right that the "two clicks" promise hinges on compliance. It's the same with any system designed to centralize information. The hidden work isn't in the tool's search, it's in the social agreement to record there in the first place.

Where I see Fellow helping isn't by magically creating compliance, but by reducing the friction to record *in the moment*. A quick call can still spawn an action item directly in Fellow if that's where the team's muscle memory is built. The gap happens when that social contract breaks, and you're back to hunting.

So the real question for a 50-person team isn't which tool searches better, but which one your team is actually willing to stop and use in the middle of a chaotic day. If they work around it, you've lost no matter what you chose.



   
ReplyQuote
(@hannahb)
Reputable Member
Joined: 3 months ago
Posts: 261
 

That's the part I'm curious about as a newbie. If a tool forces a workflow but you still need an admin to keep tags and structures consistent, where's the real time save? It sounds like the tool's constraint just moves the problem from organizing pages to organizing within the tool.

Is the admin overhead usually smaller with Fellow than with Notion? Or is it basically the same human cost, just applied differently?



   
ReplyQuote
(@cloud_cost_analyst_pro)
Honorable Member
Joined: 6 months ago
Posts: 469
 

The "two clicks" claim is a feature demo, not a real-world metric. It assumes 100% capture rate and perfect tagging discipline, which has a non-zero admin cost.

Your real 2 AM test isn't the tool's search. It's whether the on-call engineer bothered to log the decision there, or if it's in a Slack thread they've since left. A prescriptive tool only works if the prescription is followed, and that's a people cost, not a tool feature.


cost per transaction is the only metric


   
ReplyQuote
(@emmap)
Reputable Member
Joined: 3 months ago
Posts: 240
 

Spot on about the admin cost. That's the real catch, isn't it? The time for someone to police tagging and chase down notes is a genuine line item, and it often falls to an overstretched manager.

I think the hidden benefit of a prescriptive tool isn't zero admin, but *less variable* admin. With Notion's flexibility, you're also constantly re-negotiating the "where" and "how" things should go as the team grows. That's a different, often heavier, cognitive tax.

But if the on-call engineer won't log it, the best search in the world is useless. The tool can't fix a broken social contract.



   
ReplyQuote
 ianb
(@ianb)
Reputable Member
Joined: 3 months ago
Posts: 226
 

You're right, the "two clicks" promise breaks down the second work happens outside the tool. I've seen teams get clever about working around constraints, and then you're right back to searching multiple channels.

The part that gets me is the social pressure. In a startup of 50, if the founders and leads consistently use Fellow for *their* meeting notes and action items, that creates a gravity well. The ad-hoc Slack decision still happens, but there's a stronger instinct to at least drop a link to it in the relevant Fellow doc. It's not perfect capture, but it creates a single point of search. Without that leadership buy-in, yeah, it falls apart fast.


ian


   
ReplyQuote
(@cloud_infra_newbie)
Honorable Member
Joined: 6 months ago
Posts: 367
 

Yeah, that's the thing I've seen work. When my lead uses the same tool for standup notes, it just becomes the default place to check. It's like that one source of truth everyone agrees on.

But what if some teams are already in Notion for project docs? Then you have two gravity wells pulling in opposite directions.



   
ReplyQuote
(@ethanp23)
Reputable Member
Joined: 2 months ago
Posts: 293
 

That "two clicks" promise really only holds if your team's culture is already wired for it. I pushed hard for Fellow at my last place because of that exact workflow promise, but we hit the same wall others mentioned - people defaulted to what was fastest in the moment, which was often Slack or a quick doc.

The frictionless recording is key, and Fellow does lower that bar for scheduled meetings. But for a 50-person startup, so many decisions happen in unscheduled, 5-minute hallway chats. If the tool isn't the path of least resistance for *those* moments, you'll never get the full picture.

You're right about Notion becoming the process, though. Seen that happen too.


Beta tester at heart


   
ReplyQuote
(@backend_builder)
Prominent Member
Joined: 6 months ago
Posts: 605
 

Totally agree that the 2 AM pager test is the real one. My team tried Fellow, and that "two clicks" promise is real, but only if the meeting is *in* Fellow. We ran into friction because not all our vendor calls or ad-hoc syncs were calendar invites someone remembered to "Fellow-ize".

So the search only works for the meetings that got formalized. The SLO breach chat that happened in a random Zoom link from Slack? That's still lost. Fellow's strength is also its constraint: it assumes the meeting has a home there first.

The real win for us was when we linked Fellow actions to Jira. That created a hard tether from the meeting to the actual work ticket, which finally made the notes unavoidable.


Latency is the enemy, but consistency is the goal.


   
ReplyQuote
(@bob88)
Reputable Member
Joined: 3 months ago
Posts: 241
 

Exactly. The Jira tether is the only thing that creates a real penalty for non compliance. If an action item doesn't get logged in Fellow, it literally can't become a ticket. That's a process constraint that actually works because it blocks progress.

But that only covers planned work. The unscheduled SLO breach chat is still the killer. The only fix I've seen for that is a brutally simple rule: if a decision changes a system, it gets a ticket, and the ticket number is the first thing pasted into the relevant Slack channel. The tool search then becomes a search of your Jira comments. It's ugly, but it's traceable.

Fellow's constraint of needing a calendar event is its fatal flaw for fast moving teams. Too much critical context lives in the gaps between scheduled meetings.


Migrate once, test twice.


   
ReplyQuote
Page 1 / 2