Before we wrote a single formula or built a single database, we spent time understanding why Notion templates fail. Not fail to sell — fail to stick. The number of creators who've duplicated a Notion template and abandoned it within a week is enormous. We wanted to understand why before we added to the pile.
What we found wasn't surprising in hindsight, but it was clarifying: the templates that get abandoned aren't abandoned because they're bad. They're abandoned because they're overwhelming. Too many databases. Too many properties. No guidance on where to start. A blank table that stares back at you and offers no indication of what to do next.
"Complexity without purpose is just friction. And friction, for a creator who already has too much on their plate, is fatal."
That became the central design constraint for The Creative Pillar: every decision we made had to reduce friction on day one without sacrificing depth over time.
The three failure modes we designed against
1. The empty table problem
Open any database in a freshly duplicated Notion template and you're looking at a blank table with a list of property columns and no entries. The formulas show errors. The relations point nowhere. The rollups calculate nothing. It looks broken — because functionally, it is. You have to put data in before the system does anything useful, but there's no guidance on what data to put in or why.
Our solution was sample data. Every database in The Creative Pillar ships with pre-loaded examples — real, representative content that shows every formula working before you've added a single entry of your own. A viral video and a flop, side by side, so you can see what the Performance Score formula does when the inputs differ. An elite hook and a weak one, so the Hook Effectiveness score means something immediately. A live trend and a dead one, so the urgency rating makes sense.
Sample data isn't a shortcut. It's the difference between a system that teaches itself and one that requires you to figure it out alone.
2. The depth-as-barrier problem
The second failure mode is less obvious: templates that put all their depth in front of you at once. You open the system and you see 26 databases, 37 properties, 10 linked views, and a dashboard that requires you to understand all of it before it makes sense. The depth is real — but it's in the wrong place. It's blocking the door instead of waiting behind it.
The solution we built is what we call the Daily Core — three databases that handle everything a creator needs to track in their first week. The Daily Log, the Content Pipeline, and Goals. Everything else in the system connects to those three and feeds data into them, but you don't need to open the other databases to get value from them. The depth is there. It's just not in your way.
We pair this with a 7-day ramp: a structured first week that adds one layer of the system per day. By Sunday, the full system is alive with your real data. But Day 1 only asks for three things.
3. The generic prompt problem
The third failure mode specifically affects AI-enabled templates: the prompts don't work. Not because they're poorly written, but because they're generic. "Summarize my content pipeline" means nothing to an AI that doesn't know what your content pipeline looks like, what properties it has, or what you call things inside it.
Every agent and every prompt in The Creative Pillar is written against the exact database names, property names, and data structures in the system. When Agent 01 says read @Idea Vault → top scored idea, it knows what @Idea Vault is, what "top scored" means relative to the Idea Score formula, and what to do with that information. The AI isn't guessing. It's following a precise instruction written for a precise workspace.
That's what agent-native means. Not "AI prompts included." Purpose-built instructions for a specific system.
The design principles that came out of this
Three principles shaped every build decision after that research:
- Surface simplicity, subsurface depth. The user experience on day one should be simple. The capability on day 90 should be vast. Those two things aren't in conflict — they require discipline to maintain simultaneously.
- Never make the user figure out the wiring. Relations, rollups, formula dependencies, agent database references — all of that is done before the product ships. The user duplicates and operates. They don't architect.
- The system earns its complexity. Every database, formula, and agent has to justify its presence with a specific job it does that nothing else handles. Anything that didn't clear that bar was removed.
Those principles are why The Creative Pillar has 26 databases and not 40. Why the onboarding points you to 3 databases on day one. Why the sample data is representative rather than decorative. Why every agent prompt specifies the exact @database it reads from.
What this means for the ecosystem
These principles carry into every system we build. The Student Pillar and the Sales Pillar will be built to the same constraints: surface simplicity, justified depth, no wiring left to the user, sample data in every database, a structured ramp from day one.
That's the N9NE PILLARS standard. Not the most databases. Not the most features. The most useful system for the person who actually opens it every day.
We're building on solid ground. Everything else follows from that.