DraftKit: The Async Collaboration Workspace Built for Substack Writers
Managing a guest post from pitch to published took me longer than writing the thing solo. DraftKit is the product I built to fix exactly that: one workspace for the draft, and the coordination.
Managing a guest post from pitch to published took me longer than writing the thing solo.
I was switching between Gmail threads, a shared Google Doc, a Notion comment, and three DMs before a single paragraph was finalized.
DraftKit is the product I built to fix exactly that: one workspace for the draft, the feedback, and the coordination.
The Problem Collaboration Was Solving in the Wrong Place
Guest posting on Substack is not a writing problem. It is a coordination problem.
A writer reaches out. You agree on a topic. The draft lives in Google Docs. The feedback lands in email. The scheduling conversation happens in DMs. And by the time you are ready to publish, you have touched six different tools for a single piece of content.
The friction is not the writing. It is the overhead around the writing. And for async-first Substack writers who are not working inside a traditional editorial team, there is no tool that handles this specific workflow without requiring your collaborator to also pay for a subscription.
That is the exact gap DraftKit was built to close.
The Stack
DraftKit is built on:
✅ Lovable — product development and interface
✅ Supabase — database and auth
✅ Resend — transactional email
✅ TypeScript — application logic
✅ Stripe — payments and subscription management
No agency. No co-founder. No external dev team. I shipped the entire product solo in under 30 days.
The PRD Decisions That Changed Everything
The Feature I Thought Would Drive Revenue Was Wrong
Before I wrote a single line of code, I mapped out the product. The calendar was going to be the thing people paid for. Editorial planning, publishing schedules, content pipelines. I was convinced that was the value proposition.
The first wave of real users told me otherwise within two weeks. The writing workspace itself, the place where the draft lived and the feedback happened, was where people spent all their time. The calendar barely got touched.
That single signal changed the entire product direction before I built the wrong thing at scale. I stopped treating the calendar as a primary feature and rebuilt the workspace as the core product. That is the kind of feedback that only comes from shipping early and watching real behavior instead of running surveys.
I Refused to Let Subscription Walls Kill Collaboration
There is a well-documented pattern in SaaS tools built for teams: the tool is useful, the person invites a collaborator, the collaborator hits a paywall, and the original user abandons the tool rather than asking their guest to pay.
I watched this happen repeatedly with tools Substack writers were already using. A guest writer should never have to buy a subscription to leave feedback on your draft. That is a tax on collaboration, and it kills the network effect that makes a tool like this worth anything.
So I built a credit-based guest access model. The writer who owns the workspace buys credits. Their collaborators get access without a subscription. This decision came directly from watching where writers dropped off in competing tools, and it is the one product choice I am most confident was correct.
Shipping Speed Was a Product Decision, Not Just a Timeline
I made a deliberate choice to ship the MVP in under 30 days using Lovable instead of a traditional development process. The build speed is not a flex, it is a data point about what is possible when you use prompt-led development for a focused, well-scoped product.
The constraints of building fast forced better scoping. I could not over-engineer the feature set. I had to identify the minimum viable coordination layer and ship it. That discipline is visible in the product: DraftKit does one thing well instead of five things poorly.
What the Numbers Look Like
~50 active users after launch, with no paid acquisition
Built and shipped solo in under 30 days
Zero traditional dev process. Lovable, Supabase, and a clear PRD.
Guest access credits adopted by the majority of active workspaces
The metric I watch most is not signups. It is the number of workspaces that have at least one active collaborator. That number tells me whether the coordination layer is actually working, or whether people are using DraftKit as a solo writing tool. The data says the collaboration model is landing.
Who DraftKit Is For
DraftKit is built for:
✅ Substack writers who run guest post programs
✅ Newsletters with a co-author or editorial collaborator
✅ Solo creators managing content contributions from their community
✅ Writers who need async feedback without forcing collaborators onto another platform
DraftKit is not the right tool if you are a solo writer with no external collaborators. It is also not a full editorial project management platform. It is a focused async collaboration workspace, and that focus is intentional.
The Technical Layer That Makes It Work
Supabase handles the auth and the database. Every draft, comment, and workspace state is persisted in real time. Resend manages the transactional email layer: invites, notifications, and workspace activity summaries. Stripe handles the credit system cleanly without requiring a custom billing build.
The architecture is intentionally boring, which is why it works. There are no clever custom solutions where a standard tool does the job. Every technical decision prioritized reliability over novelty.
Try DraftKit
If you run a Substack with guest contributors, collaborators, or co-authors, DraftKit removes the coordination overhead that was never supposed to be your job.
If you want to talk about the product decisions behind the build, or if you are auditing a similar collaboration tool and want a second set of eyes, book a product audit at promptledproduct.com/audits.