Sometimes the best Notion advice is: don’t build it in Notion.
In January I was working with a client on a complex capacity planning setup. Multiple databases pulling from each other, external integrations feeding data in, layered automation handling updates. We spent weeks refining it, mapping dependencies, testing edge cases, making sure nothing broke when the team scaled.
From a systems perspective, it was solid. But the more we refined it, the clearer something became.
We were building the right solution in the wrong place. Like trying to use a Swiss Army knife when you really need a proper toolbox.
Capability vs Suitability
Notion is powerful — it can handle way more than most teams use it for. But just because it can handle something doesn’t mean it should.
There’s a difference between capability and suitability.
So I said something I don’t usually say: use another tool for this part. Keep Notion as your single source of truth, but don’t force it to become your entire tech stack. Let the capacity planning live where it’s actually designed to live, and connect it back to Notion for visibility.
Here’s what surprised me: that recommendation built more trust than any clever automation ever could.
The Question That Guides Me
My job isn’t to prove what Notion can do. It’s to design what actually serves the team. And sometimes serving the team means pointing them somewhere else.
Is this what’s best for the team, or am I just showing off what’s possible?