Before I wrote the first line of code, I had a clear picture of what DraftKit would be. A coordination tool for Substack writers, built around a calendar.
Writers would book dates, manage their collaboration schedule, and the calendar would be the thing that made them pay.
I was wrong about the most important part.
The writing workspace, the place where the actual draft lives, turned out to be where users spent all their time.
The calendar is still in the product, but it is not the reason people stay.
The Feature I Built That Nobody Wanted
The original DraftKit roadmap included a feature I was genuinely excited about: Virtual Coffee. The idea was a lightweight 1:1 meeting type, a way for writers to have a short call to explore a potential collaboration before committing to anything.
I built it. It shipped. And it sat there.
Nobody was booking Virtual Coffees. The writers using DraftKit were not looking for another meeting on their calendar. They wanted to skip the discovery call entirely and get straight to the draft. The async-first model, where someone submits a collaboration request, gets approved, and both parties start writing immediately without a live call, was what actually matched how they worked.
I removed Virtual Coffee from the collaboration types. That was the easy decision. The harder one came when I looked at the calendar data.
What the Calendar Actually Is
Here is what I expected: the calendar would be the thing people paid for. Manage your editorial schedule, see your booked collaborations, plan your publishing cadence. That would be the hero feature.
Here is what actually happened: users opened the calendar to check their availability, approved or declined requests, and then spent the rest of their time in the workspace editor.
The calendar did not lose its purpose. It still does something real: it shows available dates on your public booking page, prevents double-booking, and gives both parties a shared reference point for when a collaboration is due. Those are necessary functions, and I kept them. But the calendar is not why DraftKit is worth using. It is infrastructure, not a destination.
This is a distinction that matters when you are building. A feature can be necessary without being valuable. Necessary means the product breaks without it. Valuable means users actively choose to engage with it. The calendar falls into the first category. The workspace is firmly in the second.
The Decision That Changed the Product Direction
When it became clear the workspace was the real product, I had two choices. Keep building calendar features on the assumption that usage would follow, or redirect that energy toward the workspace.
I redirected. The workspace got tables. It got sticky highlights for inline async annotations. It got long-form scaling to handle drafts up to 50,000 words. It got a real-time presence system. It got a SMART Draft generator that pulls RSS feeds from both writers and generates a structured first draft with section assignments.
Every one of those decisions came from watching what users were actually doing instead of what I assumed they would do. None of them were on the original roadmap.
The Guest Access Model Came From the Same Observation
The credit-based guest access model was also an assumption I had to update. My original thinking was that both parties in a collaboration would need a DraftKit account. That seems reasonable until you watch what happens: the writer with the account invites a collaborator, the collaborator hits a signup wall, and the original user abandons the tool because they are not going to ask their guest to sign up for something new.
I had seen this pattern in other tools. Writers were using Google Docs not because Google Docs is better for collaboration, but because Google Docs does not make you pay to leave a comment.
The solution was the Host-Pays credit model. The creator who owns the workspace spends one credit when they approve a collaboration. Their collaborators get full workspace access without a subscription. The person who is already bought in covers the cost. The guest never hits a wall.
That single decision is visible in the product metrics. The majority of active workspaces have at least one collaborator who does not have a paid DraftKit subscription.
What I Would Do Differently
The honest answer is: I would have watched the first ten users more closely before building anything past the core collaboration request flow.
I shipped fast. Under 30 days from first prompt to live product. That speed was real and it was valuable, but it meant I built a full calendar management system before I had confirmed evidence that calendar management was the problem people needed solved.
The Virtual Coffee feature cost maybe three days of build time. The rethinking of what the product actually was cost nothing in build time but required accepting that my original product vision was partially wrong.
The willingness to call a feature unnecessary, even one you shipped, is more valuable than any specific technical skill. I cut Virtual Coffee. I repositioned the calendar as infrastructure. I put everything into the workspace. The product is better for all three decisions.
What DraftKit Is Now
DraftKit is a writing workspace for Substack writers who collaborate. The calendar is how you manage availability and scheduling. The workspace is where the actual work happens.
The collaboration types that perform well in practice are all async-first: Async Drafting, Guest Post Exchange, Interview Style, Co-written Article. These are formats where writers need a shared editing environment, not a meeting.
The product does one thing better than anything else: it puts the draft and the collaboration in the same place so writers do not have to manage them separately.
Try DraftKit
If you run a newsletter and you work with guest contributors, co-authors, or interview subjects, DraftKit removes the coordination overhead that was never supposed to be your job.
If you are building a similar tool and want a second opinion on your feature prioritization before you build the wrong thing, book a product audit at promptledproduct.com/audits.