Check out the Build Series. Part 1 | Part 2 | Part 3 | Part 4 | Part 5
Most shadow use cases die quietly. A creator finds a workaround, keeps using it, never files a feature request, and eventually churns when the friction gets too high. I nearly let that happen with DraftKit.
Three months after shipping the solo workspace feature, I opened the admin analytics and scrolled through workspace titles. Solo workspaces show whatever text the creator entered when they hit “Start Writing.”
One creator had eight workspaces named “Part One,” “Part Two,” all the way through. Another had workspace titles like “Chapter 1 Origin Story,” “Chapter 2 The Pivot,” “Chapter 3 Revenue.”
And a third had numbered their drafts sequentially with dates appended, one per week, going back two months.
They were writing books inside a collaboration tool designed for single-article partnerships. Not because they wanted to, but because DraftKit was the closest thing they had to a structured writing environment.
The gap was obvious once I saw it: DraftKit handled one article at a time, but some creators think in libraries. A complete technical guide spread across eight separate workspace URLs is a product failure dressed up as user creativity.
The Creator Economy Is Writing Books. The Tools Still Serve Single Articles.
The long-form content shift is real. Substack crossed 8.4 million paid subscriptions in Q1 2026, up 68% from five million in March 2025. At the same time, nearly 100,000 publications now earn money globally on Substack as of April 2026, double the figure from May 2025. More paying subscribers means more creators producing at volume, and volume changes the unit of work.
The solo “quick take” newsletter is not going away. But it is getting company. Serious creators are writing multi-part guides, book-length references, and technical series that run 30,000 words or more. beehiiv’s State of Newsletters 2026 found that subscription revenue on their platform grew 138% in a single year, driven specifically by niche creators delivering specialized, in-depth expertise, not short-form takes.
Most collaboration tools built for newsletters give creators:
✅ A single document editor per piece
✅ A basic co-author invite flow
❌ No chapter structure or ordering
❌ No project-level membership control (owner vs. editor vs. viewer)
❌ No broadcast function to notify every collaborator at once
The pattern is the same everywhere. The tools were designed for the unit of one newsletter, not the unit of one book.
The workaround costs more than people realize. Eight workspace tabs mean eight separate URLs to manage, eight separate “last edited” timestamps to track, and no way to see the project as a whole. When the workaround gets painful enough, the creator leaves for something that was built for them.
Why Your Workflow Misses This
Product teams build for the median user, not the top 5%. The median creator publishes once a week, writes 800 words, and needs a clean editor. That creator does not need a chapter structure. But the creator in your top 5% is the one who refers 10 new users, writes the technical guide that gets shared 3,000 times, and stays subscribed for years because the product serves their ambition, not just their baseline.
When a power user builds a workaround, they are not being creative. They are telling you exactly what to ship next. The only question is whether you catch it before they churn.
Writers like Lenny Rachitsky have been making this argument about product teams for years: your most engaged users are your product roadmap, if you bother to look at what they are actually doing rather than what they say they want in surveys.
The Approach I Follow
Before shipping Book Projects, I made five decisions that shaped everything else:
✅ Ship a separate feature, not an extension. The temptation was to add a “series” or “folder” layer on top of the existing workspace. I rejected it. A collaboration workspace is designed around one relationship and one date. A book project is designed around one creative work and many contributors over time. Those are different data models, and forcing one schema to serve both creates technical debt immediately.
✅ Build real role structure. Owner, editor, viewer. A book project needed a clear access hierarchy, not the binary “host and guest” from a collab workspace. A co-author contributing every chapter has different needs than a developmental editor with read-only access. The role check has to live in the database, not just the UI.
✅ Handle image storage differently. Workspace images use public URLs so they render in any browser without authentication. Book project images use signed URLs with expiry because project content is private creative work until the creator decides to publish. Same underlying Supabase Storage infrastructure, different access pattern at the RLS layer.
✅ Add a broadcast function. With multiple chapters and multiple contributors, creators needed a way to send one announcement to the entire project team. Email threads get messy when collaborators are in six different time zones. The broadcast needed to live inside the product, not get outsourced to a Slack message no one reads.
✅ Gate it behind Pro. Long-form book projects serve the most serious creators and require more infrastructure: storage compute, chapter rendering, broadcast emails. Making it Pro-only kept the economics honest and gave paying users a meaningful reason to upgrade beyond just unlimited collabs.
If your AI product has a user segment working harder than the feature was designed for, you have a Pro tier in waiting. Book a product audit at hello@elenacalvillo.com and we will find it together.