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.

Try DraftKit at draftkit.app

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.

DraftKit has two AI features that pick up exactly where that blank document problem starts: SMART Match surfaces what you should write together before you commit, and SMART Draft builds the first structured outline after you do.

Here is exactly how both work under the hood.

SMART Match: AI Before the Commitment

SMART Match runs on the public booking page. When someone visits your DraftKit profile and enters their Substack URL into the collaboration request form, the AI kicks in before they even hit submit.

The analyze-collab-match edge function fires as soon as the URL is entered. It fetches the RSS feeds from both newsletters: yours and your potential collaborator’s. It sends both content libraries to the AI through the Lovable AI Gateway, which routes through Google Gemini and OpenAI models depending on load.

The function returns three specific collaboration topic ideas, each with a format recommendation and the source articles it used to generate the suggestion.

A typical result looks like this: a topic, a one-sentence explanation of why it works given both audiences, a suggested format (co-written article, interview, newsletter shoutout), and pointers to the specific posts from both newsletters that informed the suggestion.

Why RSS Feeds and Not Something Fancier

I could have built a richer content analysis layer. Profile scraping, engagement data, subscriber overlap estimates. I did not, for two reasons.

First, RSS feeds are public and reliable. Every Substack publication has one. The content is clean, structured, and requires no authentication. I do not need to scrape anything or handle authentication failures.

Second, topic matching based on what someone has actually written is more useful than matching based on anything else. If someone has published 12 posts about AI tooling and you have published 8 posts about product strategy, the overlap is obvious from the text. No engagement data needed.

The rate limiting reflects the cost model. Unauthenticated visitors get 10 SMART Match requests per hour. Authenticated users get 50. That is enough for real usage and keeps the edge function budget manageable.

SMART Draft: The AI Layer After the Yes

SMART Match happens before a collaboration is confirmed. SMART Draft happens after.

When a host approves a collaboration request, they can trigger a first draft through the generate-collab-draft edge function. The function does three things:

• ✅ Fetches RSS content from both participants’ newsletters

• ✅ Combines the content with the collaboration context: the type of collab, the date, any message the requester included

• ✅ Returns a structured draft object, not freeform prose

The returned draft is not a finished article. It is a scaffolded outline with a title, a hook, an ordered section breakdown with contributor assignments per section, talking points for each section, format suggestions, tone notes, and an estimated read time. The host reviews it in the workspace sidebar and decides whether to apply it to the editor.

The Re-Apply Guard

This is the detail I am most glad I built. The first version of SMART Draft had a straightforward “Apply to Workspace” button. Click it, the draft populates the editor, done.

The problem is what happens on the second click. If you have applied a draft, made edits, written two paragraphs of real content, and then accidentally click “Apply” again, you lose everything you wrote.

The re-apply guard prevents that. After a draft is applied for the first time, the button becomes a confirmation step. A prompt tells you that the workspace has been edited since the draft was last applied and asks you to confirm before proceeding. The re-inject only happens on explicit confirmation. Manual edits are never overwritten silently.

This was a bug I caught before it became a support ticket. Building the guard took less than an hour. Not building it would have cost someone a draft they could not recover.

No API Key Required

Both AI features run through the Lovable AI Gateway. This is worth explaining because it is a meaningful architectural choice.

Most AI product builds require you to manage your own API keys: OpenAI, Anthropic, Google. You handle authentication, rate limits, billing, and model selection. The Lovable AI Gateway abstracts all of that. The edge functions call the gateway endpoint with no external API key required.

The tradeoff is reduced model control. I am not selecting a specific model version or tuning temperature settings. For content matching and first-draft generation, that tradeoff is fine. The quality is consistent and the operational overhead is near zero.

If I ever need more control over the AI layer, the gateway is a single abstraction point to replace. One edge function to update, not a dozen places where API keys and model names are scattered.

What SMART Draft Does Not Replace

SMART Draft is not a ghostwriter. It is scaffolding.

The output is useful because it solves the specific problem of starting a collaborative document from scratch. Two writers, one blank editor, and the implicit question of who writes what. The draft answers that question with section assignments and talking points. Both parties know where to start.

The writing is still yours. The SMART Draft is a starting structure, not a finished article. In practice, most collaborations that use SMART Draft end up with content that looks nothing like the original draft by the time it is published. That is exactly what it is supposed to do: reduce the friction of starting without replacing the work of finishing.

The Storage Model

SMART Draft outputs are stored as JSON in collab_requests.ai_draft. The field preserves the full structured draft independently of the workspace content. If the host applies the draft and then the collaborator rewrites everything, the original SMART Draft is still in the database.

This matters for two reasons. First, it gives me product intelligence on which SMART Draft suggestions actually made it into published collaborations. Second, it means the draft can always be re-applied or reviewed from the sidebar without regenerating it.

The ai_suggestion_used field tracks which elements of the SMART Match output the collaborator actually included in their request form. That data feeds back into improving the matching logic over time.

Try DraftKit

SMART Match and SMART Draft are live on every DraftKit account. Try them at draftkit.app

If you are building AI features into a collaboration product and want a review of your AI interaction design before launch, book a product audit at promptledproduct.com/audits.

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.

Try DraftKit at draftkit.app

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.

The collab_requests table is the core entity, and every feature, from guest access to workspace permissions to metrics, flows through it.

Here is exactly how I designed it and why.

Why One Table Handles the Whole Lifecycle

When I started designing the schema, the obvious instinct was to split things up. A workspaces table, a separate collaborations table, a drafts table. That would have been three tables to keep in sync, three places for a status to get out of sync, and three surfaces for an RLS policy to go wrong.

I chose a different approach. Every collaboration, whether it is an inbound guest post request, an outgoing proposal, or a solo draft someone created with the “Start Writing” button, is a row in collab_requests. The status field does all the state management: pending when someone submits a request, approved when the host accepts, published when the collab goes live, and cancelled when it falls through.

The shared workspace editor content lives directly in collab_requests.shared_content as sanitized HTML. There is no separate drafts table. The workspace is not a separate entity. It is a view into the state of a single row.

The Fields That Drive the Core Product

The table has fields most collaboration tools would put in three separate tables. Here is what matters most and why each field exists:

• ✅ is_solo (boolean) — when a creator hits “Start Writing” and opens a blank workspace with no collaborator, it creates a collab_request with is_solo: true and status: 'approved'. Solo drafts use the exact same workspace, the same editor, the same RLS policies. No special-casing anywhere.

• ✅ shared_content (HTML) — the live draft text. DOMPurify-sanitized on every save, with a tag whitelist that allows tables, images, and sticky highlights but blocks everything else. No base64 images, ever: the sanitizer strips them.

• ✅ ai_draft (JSON) — the SMART-generated first draft, stored separately from the live content. Hosts can generate it, preview it, and apply it to the workspace. A re-apply guard checks for manual edits before overwriting.

• ✅ editing_sessions (JSON array) — tracks who edited, when, and for how long. Not for billing. For product intelligence: which workspaces are actually being used versus opened once and abandoned.

• ✅ content_last_edited_by / content_last_edited_at — presence-aware fields that power the “someone else is editing” indicator without needing a separate real-time table.

The Credit Model Lives in the Schema

DraftKit runs on a Host-Pays credit model. The host spends one credit when they approve a collaboration or create a solo workspace. Guests never pay.

That logic is enforced at the database level, not just the application layer. The creators table has a credits column defaulting to 3. The get_host_capacity() RPC returns the current available balance including referral bonuses. When a host approves a request, the credit deduction happens server-side before the status update.

Pro users bypass this entirely. is_pro_user(user_id) checks three conditions: the user_roles table for a pro role, the creators.subscription_tier column, and an active trial window. If any of those is true, no credit is deducted. A Founding Member who cancels their Stripe subscription still has the pro role in user_roles, so their access survives the cancellation.

The RLS Architecture

Row-Level Security is the enforcement layer for every permission decision in DraftKit. Here is the actual policy logic, not a simplified summary:

Anonymous users can INSERT a collab_request with status = 'pending'. That is what makes the public booking page work without auth. But they cannot SELECT anything. A guest filling out a booking form on draftkit.app/elena has zero read access to the database.

Once a collaboration is approved, access opens up through a single helper function: has_workspace_access(user_id, request_id). This function checks three conditions: is the user the host creator, is the user the original requester, or is the user listed in workspace_collaborators for that request. If any of those is true, the user gets full read and write access to the workspace.

The host-only restriction on Writer’s Room invitations is also enforced at the RLS level. Only the request owner can INSERT into workspace_collaborators. A collaborator who has been invited cannot invite additional people. That is “Host Home Court Advantage” and it is a policy, not a UI constraint.

The Permanent Access Rule

One of the most important schema decisions I made was around access persistence. Once a host spends a credit to unlock a workspace, that access is permanent. Downgrading from Pro to free does not lock anyone out of past work. Cancelling a subscription does not revoke access to approved collaborations.

This is intentional. Credits are an entry toll, not a recurring subscription. The has_workspace_access() function does not check current plan status. It checks whether the workspace was ever properly unlocked. That is a one-time event recorded in the collab_requests row itself.

The practical implication: if you approved a collaboration six months ago and then downgraded to free, you and your collaborator still have full access to that workspace. The credit was spent. The workspace is yours.

What the Supporting Tables Do

The core collab_requests table is not the whole picture. A few supporting tables handle the pieces that would otherwise bloat the main row:

• ✅ workspace_collaborators — multi-guest support (the Writer’s Room). Stores email, user_id, role, and join timestamp per invited collaborator. RLS-gated so only the host can insert.

• ✅ workspace_presence — real-time presence indicators. Heartbeat polling updates last_active_at per user. Shows the green dot in the Writer’s Room sidebar.

• ✅ collab_metrics — post-publication engagement snapshots. After a collaboration is marked “Published”, both parties enter their Substack post URLs and the metrics edge function pulls likes, comments, and subscriber counts. Stored as snapshots so the data is preserved even if the Substack post is later edited.

• ✅ collaboration_messages — the threaded conversation feed inside the workspace. Free users see the most recent message; older messages are gated behind Pro. The blurring is applied client-side but the data access is controlled server-side.

The Decision I Would Make the Same Way Again

Some product decisions feel uncertain for a long time. This one does not. Treating the workspace as a state on the collaboration row, rather than a separate entity, is the right architecture for this product.

It means every historical collaboration is fully queryable from a single table. It means the analytics RPC is straightforward. It means there is one source of truth for status, access, content, and metrics.

If you are building a collaboration product and you are debating whether to separate the “workspace” from the “collaboration,” my answer is: do not, until you have a specific technical reason that forces the separation.

Try DraftKit

The full collaboration infrastructure is live at draftkit.app.

If you are building a similar product and want a technical review of your data model and access architecture, book a product audit at promptledproduct.com/audits.