- Authors
Many Tools, No Rules
Notion, Slack, Figma, Google Drive. Pretty much every startup uses them. We did too.
The problem came after that. "Where should I put this?", "Is that doc in Notion? Or Slack?", "Oh that's in Google Drive... which folder was it again?" These questions kept coming up.
More tools actually made things more confusing. Without clear roles for each tool, the same info ended up scattered everywhere. We couldn't tell what was up to date, and kept wasting time asking the same questions.
It got worse with new hires. When they asked "Where do I find docs?", all we could say was "Check Notion first... then maybe dig through Slack... could be in Google Drive too..."
Time to Fix This
Switching tools wasn't the answer. The tools were already good enough.
The problem was no defined roles. We never decided what goes where, or how tools connect to each other.
So we decided to structure the whole workflow.
The Structure
Looks complicated, but the core is simple.
Internal Tools → Output → External
That's the only flow that matters. We defined what each tool does at each stage.
And this structure was built with AI in mind. When Markdown docs pile up in the Output stage, AI can reference them. Hook it up with Claude Code or MCP, and you get internal knowledge search, content generation, planning ideas, and more.
Internal Tools: Each Tool's Role
We gave each tool a clear role. Every tool has a desktop app installed so we get notifications.
Notion: The Hub
Role: Center of all information
Notion is the hub where links from other tools come together. We write docs there too, but what matters more is systematically collecting links from other tools.
- Meeting notes, specs, project docs
- Figma design links
- Google Drive file links
- Important Slack thread links
"Where is this?" The answer is always Notion. Even if the actual file lives somewhere else, you should be able to find it from Notion.
Slack: Real-time Communication
Role: Conversations that flow
Slack is for real-time discussion and quick decisions. But since Slack conversations flow and disappear, anything worth keeping must move to Notion.
When an important decision happens in Slack:
- Save the thread link to Notion
- Or write it up as a Notion doc
No important info should only exist in Slack.
Figma: Design Collaboration
Role: UI/UX design and visual assets
Figma is for design work and visual materials that need a big screen. We share links that go directly to specific objects, not whole files.
Google Drive: Notion's Backup
Role: Handles what Notion can't
Google Drive only handles what Notion isn't good at:
- Spreadsheets (calculations, data tracking)
- Large files (PDFs, videos, bulk images)
Files in Google Drive still get linked from Notion so you can find them there.
Adding Linear: Separating Project Management
We used to manage projects in Notion too. The database features are powerful, so we thought it'd work great.
But there were problems.
Too Much Freedom
You can change anything in Notion. That was both a strength and a weakness.
One team member accidentally edits something, and the whole structure breaks. High flexibility means harder management.
Had to Build the System Ourselves
Database schema design, setting up relations, creating filters and views...
We spent more time building the system than actually managing tasks.
Hard to Maintain
One small mistake and the structure we built would break. Recovery took forever, and new features meant more time investment.
It got worse as the team grew.
Switching to Linear
So we brought in Linear.
Tools specialized for project management should do project management. Linear just needs to be good at that. Notion can focus on being the doc hub.
In Linear:
- Task: Feature development, doc writing, todo management
- Bug Tracker: Bugs from Product, CS issues
Results from Internal Tools (meeting notes, specs, etc.) get linked to Linear tasks.
Output: Where Results Take Shape
This is where work from Internal Tools becomes actual deliverables.
Markdown: Version-Controlled Docs
Core docs are written in Markdown and version-controlled with GitHub.
These include:
- Core values and vision
- Official roadmap per feature
- Product philosophy, design principles
- User guides, tutorials
Why Markdown?
- Accurate version control: Git tracks all change history
- No accidental edits: PR reviews required before merging to GitHub
- Easy integration: Plain text files readable anywhere
- Publishable: Auto-deploy doc sites with Docusaurus, GitBook, etc.
Dev: Development Work
Writing code, building features, fixing bugs. Actual development. Code lives in GitHub, quality managed through PR reviews.
AI Integration
One reason we organized the workflow was AI.
It makes giving context to AI way easier.
When using Claude Code or connecting tools via MCP, having organized information for AI to reference makes everything more effective.
When Markdown docs pile up:
- Internal Knowledge Search: Answer questions from docs, onboard new hires
- Visual Content: Generate images and videos from docs
- Planning: AI analyzes docs and suggests ideas
- Idea: Brainstorming, new feature suggestions
You can connect Notion to AI via MCP too. But having Markdown files locally means no extra setup—just feed them straight as context, and search is faster. Having all docs in the file system is a clear advantage for AI.
Organized information means AI can actually be useful.
What Changed After
"Where should I put this?" Gone
Clear roles mean no more wondering. We used to dig through Slack, then Notion, then Google Drive just to find one doc. Now it's just Notion. Time spent finding docs cut by more than half.
Onboarding Got Faster
Tell new hires "Start with Notion" and you're done. We used to spend ages explaining each tool and where everything lives.
Adding New Tools Got Easier
With a structure in place, new tools have a clear spot. Just define "This tool handles this role in Internal Tools" and you're set.
Conclusion
It's not about changing tools. It's about defining roles for the tools you already have and creating a flow.
This isn't the end. We'll keep changing if we find better ways. New tools might come in, current ones might get dropped or reassigned.
What matters is having a structure at all. When you have a baseline, change is easy.