Last November I was shipping the AI Advent Challenge under real constraints.

30+ contributors. A $50 budget. A hard public deadline. And somewhere in the middle of firefighting a content crisis five days before launch, my inbox started filling up with a different kind of problem.

Collaboration requests. Writers wanting to co-author posts. Founders wanting to do joint content. People I genuinely wanted to work with.

I had no intake system. No way to communicate my process quickly. No shared workspace. No scheduling layer. Nothing that could handle an inbound request without pulling me fully out of build mode.

So I did what any overloaded PM does when there is no process for something: I said no. To every single one.

That is not a writing problem. That is an infrastructure problem. And after the launch, I sat down and ran the audit I should have run months earlier.

I Break AI Tools So You Don’t Have To

While I was tearing down my own system, I realized I should be doing this for yours, too. I’ve officially started doing Product Audits.

If you’re building a product and want a Senior PM to find the exact friction point where your users give up, I’m opening up slots. I’ll audit your prompt architecture and stress-test your logic before your users do. You can book a Product Audit here.

The Audit: 8.5 Hours Per Collaboration

I analyzed the data across my 2025-2026 Collaboration Workflow Research and mapped the average coordination loop into four buckets. This is the analysis you would run on any broken product workflow before designing a fix.

• Outreach and qualification (2 hours): Cold DMs and follow-ups. Two hours spent just confirming another party is open to a conversation. In product terms, this is a broken intake process with no triage layer.

• Discovery and alignment (1.5 hours): Figuring out if there is a fit. This almost always becomes a synchronous call even when an async form would answer the same questions in ten minutes. Classic “meeting that should have been an email.”

• Ideation (1.5 hours): Two parties trying to define the scope of a shared deliverable with no pre-work. The output is a vague direction and no committed next step.

• Coordination overhead (3.5 hours): “Where is the file?”, “Is the draft ready?”, “When are we publishing?”. This is pure async thrash with no single source of truth.

The research I ran across 2025 and 2026 collaboration workflow data confirms this is not an edge case: A single guest post takes between 7 and 11 hours end to end when you account for outreach, drafting, formatting, and coordination overhead.

A separate analysis of AI formatting tools found they save an average of 92 minutes per article on formatting alone, which tells you something about how much time the manual overhead actually consumes before you even get to the coordination layer.

But this pattern is not unique to content creators. It is the coordination tax that shows up anywhere two independent workstreams need to produce one shared output.

Some examples:

• The partner integration where two engineering teams sync through email chains.

• The co-marketing launch where assets live across four Slack threads.

• The joint spec where three stakeholders are each editing a different version of the same document.

The domain changes, yes. However, the 8.5 hours not change much.

The Product Logic

Once you have the audit, the design question is straightforward.

Where exactly does the process break, and what would replace each broken step with a system?

➡️ Outreach with no triage layer gets replaced with structured intake.

➡️ Discovery calls get replaced with async qualification.

➡️ Blank-page ideation gets replaced with AI-generated overlap analysis.

➡️ Coordination ping-pong gets replaced with shared state tracking and a defined project lifecycle.

The efficiency formula I used to measure progress:

The 1.0 represents a fully systematized workflow where intake, discovery, ideation, and tracking are handled by the tool rather than by the people. The goal is not to make coordination faster. It is to remove it from the critical path entirely.

With my first 6 collabs using DraftKit only, the cohort has already recovered 45 hours of combined focus time. Ship rate went from roughly 40% in manual workflows to 86% inside DraftKit.

That second number matters more than the first. Most collaborations do not fail because people lose interest. They fail because there is no system to carry them past the messy middle. Raising the ship rate is a systems fix, not a motivation fix.

What I Built

DraftKit is coordination infrastructure for collaborative publishing. It is not a writing tool. It is the layer that sits between “we should work on something together” and a shipped artifact, and removes every manual step in between.

I have my own profile live at draftkit.app/elenacalvillo. It is linked directly from my Substack navigation bar. When someone wants to collaborate, I send that link. They see my availability, book a date, and we move into a shared workspace. The entire qualification and scheduling loop that used to take days now takes minutes.

Here is how the three core pieces map to the problems in the audit.

Structured Intake: The Front Door

Replaces: the 2-hour outreach and qualification loop.

Your Front Door is a public profile link that functions as a collaboration intake page. It shows your focus areas, your current availability, and the kind of work you are open to right now. An inbound request lands here instead of in your DMs. The qualification happens before the first message is sent.

A potential collaborator reviews your profile and knows within a minute whether there is a fit. They book directly from your calendar. No discovery call. No scheduling thread. No “let me know what works for you.”

In PM terms: you have replaced a broken, manual triage process with a structured intake form that filters and routes automatically.

AI Overlap Analysis: The Smart Match Engine

Replaces: the 1.5-hour ideation fog.

Most collaborative projects stall before they start because neither party has done the pre-work to map where their interests actually overlap. You end up in a synchronous brainstorm that produces vague directions and no committed scope.

The Smart Match engine analyzes the content, audience, and focus areas of both parties and surfaces three specific intersection topics before the first working session. And these are not generic suggestions. Specific angles grounded in what both parties have actually built and who they are each talking to.

This is the feature I spent the most time getting right, because generic AI output here is worse than no output. The intelligence has to be in the specificity, otherwise you have just automated the blank page.

Shared State Tracking: The Shipping Dashboard

Replaces: the 3.5-hour coordination ping-pong.

Every collaboration in DraftKit has a defined state: pending, accepted, drafting, published. The dashboard shows your full project calendar, active collaborators, and what each project needs next. The Recent Requests panel gives you a live view of inbound requests and their current status.

There is no ambiguity about ownership. No async thrash about where the file is. Every writer works in a shared workspace inside DraftKit regardless of what tool they normally use, so the content never gets fragmented across Docs, Craft, Notion, or email.

In PM terms: you have replaced informal project management with a lightweight sprint board scoped specifically to collaborative publishing.

The Architecture

I built DraftKit as a Prompt-Led Product. The design constraints came from the audit. The architecture came from translating those constraints into precise prompts and iterating on the output.

Two prompts defined the core logic.

State management schema (Supabase):

Design a Supabase schema for collab_requests. It must handle four 
distinct states: pending, accepted, drafting, and published. Create 
a trigger that calculates the total_time_to_ship whenever the status 
changes to published. The schema must support a workspace view where 
two distinct user_ids can view shared files without having access to 
each other's private profiles.

This is what makes the ship rate measurable rather than estimated. Every state transition is logged. Every project has a defined finish line. The row-level security constraint for the shared workspace was the hardest part to get right and pushed me through three schema iterations before it held cleanly.

Smart Match engine (TypeScript):

Write a TypeScript function that takes two arrays of Substack 
Recommendations URLs. Identify the top 3 overlapping niches between 
these two creators. Then, generate three specific, high-level article 
titles that would appeal to a Senior Product Manager audience. Avoid 
generic phrases like The Future of AI. Focus on The Operational 
Friction of X or The Engineering Logic of Y.

The constraint in the final instruction is what separates useful output from generic output. Without it the function produces safe, broad topic suggestions that neither party would commit to. The specificity constraint forces the engine to reason from actual content overlap rather than from a general knowledge base.

🔓 The full architecture including Edge Function logic, the Lovable UI prompting strategy, and the database triggers behind the time-to-ship metric are in the Prompt Vault for paid subscribers later this week.

Where This Is Going

After the first founding users came in, two requests showed up that I was not expecting.

• One user asked about using DraftKit to coordinate a book across multiple writers, managing chapters rather than posts, with more than two contributors involved. Another asked about collaborative posts with three or four authors, not just pairs.

• And I started thinking about the next AI Advent Challenge. Every contributor coordination loop could run through DraftKit this year. Structured intake, shared workspace, defined state tracking. The infrastructure that did not exist last year is live now.

I am not announcing a roadmap change (yet). But the underlying architecture can hold more than two-party, single-post workflows, and I am paying attention to where the real demand is.

If you have a use case that goes beyond the standard two-person collaboration, reply and tell me what you are trying to coordinate. That feedback is directly shaping what gets built next.

Quick Reference

What does DraftKit replace? The DM thread where a collaboration lives and usually dies. The discovery call that should have been an async form. The Google Doc nobody can find two weeks later. The Slack message asking “where are we on this?” for the fourth time. DraftKit replaces all of it with structured intake, AI-assisted scoping, and a shared project workspace.

How much time does it actually save? Based on 6 published collaborations and 21 founding members, coordination overhead drops from 8.5 hours to roughly 1 hour per project. The 45-hour figure on the dashboard is cumulative across the founding cohort measured against the manual baseline.

Is this only for two-person workflows? The current version is built for two-party collaborative publishing. That is the specific problem I needed to solve and validate first. Where it goes from here depends on what early users actually need.

The Founding 100

I am looking for the final 49 members to close out the Founding 100 cohort.

Your first 3 collaborations are free. No credit card, no subscription trap. The cohort closes at 100 to keep the feedback loop tight while I keep iterating on the core architecture.

If you want to see the Front Door experience before signing up, my profile is live at draftkit.app/elenacalvillo.

Try DraftKit at draftkit.app

Where are you currently paying the highest “Coordination Tax” in your own projects?

Is it the endless DM threads? The “discovery calls” that go nowhere? Or the 3.5-hour “where is the link” spiral?

Leave a comment below. I am building the next phase of the DraftKit roadmap (including the “Project Wrapper” for book series and multi-part collabs) based on where your systems are actually breaking.

Leave a comment

Proof Of Work

I have been tracking the community’s latest builds in the Substack chat. The caliber of technical execution is incredible. These aren’t just articles; they are architectural blueprints for the next wave of AI products.

The Deep Dives

• Jeremy Wright - Marketer/ECHO is mastering what he calls “Structural Alchemy.” He is building ECHO, a system designed for his own exact wiring, to move from being an engineer to an investigator of friction.

  • “Structural Alchemy: How I Saved Gary.” A masterclass in using architectural logic to rescue a project. Read it here.

  • “On ECHO Being Right: I Taught Three.” An honest look at what happens when you take a system built for your own brain and try to hand it to someone else. Read it here.

• Alyssa Fu Ward, PhD is documenting the total collapse of the technical barrier. She watched her 7-year-old “vibe code” a functional app, proving that the building phase is no longer the bottleneck for a product. If the code is now a commodity, the strategy is the only edge left. Read it here.

• Cristina is tackling the mental model of the solo builder among other authors. She makes the case that trying to figure out every technical shift alone is a recipe for stagnation. The real leverage comes from community and shared discovery. Read it here.

• Alex Willen is moving beyond simple chat interfaces to full-scale automation. He is using Claude Code to architect a system for managing Amazon Ads, proving that AI is now capable of handling high-stakes, data-heavy marketing infrastructure. Read it here.

• Karo (Product with Attitude) is mastering the efficiency of Perplexity Computer. She is stripping away the hype to focus on the unit economics of building, showing how to avoid the "costly loops" that drain budgets without delivering value. This is a deep dive into "real use, not theory" for builders who need to scale their workflows responsibly. Read it here.

For paid subscribers: The full Prompt Vault drops later this week. Every master prompt used to architect and ship DraftKit, including the Supabase schema, the Smart Match TypeScript function, the Edge Function logic, and the Lovable UI strategy, is inside.