You started the project alone. Now there's someone else in the picture: a designer giving the spec a once-over, a contractor who needs to understand the scope before quoting, or a non-technical co-founder who keeps asking "what exactly are we building?" in different words.
The path of least resistance is forwarding a screenshot or a Google Doc export. It works, roughly, until the spec changes and they're looking at version three while you're on version seven.
The slightly better path is to share a Draftlytic project directly. They see the live spec, can edit sections, and don't need to be on your email chain every time you update the overview. This post covers how that works, what shared editors can and can't do, and when you're better off just exporting the markdown and sending it over.
How the collaboration model works (and who pays)
Draftlytic's sharing is available on paid plans. If you're on a paid tier and want to share a project, the pricing page explains what's included.
Adding a shared editor is straightforward: from the project page, open the share settings and enter your collaborator's email. They get an invitation, create an account if they don't have one, and land directly on the project.
Here's the part worth understanding before you invite someone: your credits pay for everything they do in the project. If a shared editor runs an AI Edit, triggers a Scan, or generates a logo round, the cost comes out of your credit balance, not theirs. This is by design. The alternative (having collaborators need their own paid account before they can make any edits) creates friction that defeats the point of sharing in the first place. But it does mean you want to share thoughtfully.
In practice, this isn't usually a problem. Most collaborators you'd add to a spec aren't going to run 15 AI Edits unprompted. But for contractors you don't know well, or in situations where you want the spec to stay stable, the coordination patterns in the next section matter.
What a shared editor can actually do
A shared editor has broad access to the project. They can:
- Read every section of the spec (Overview, Features, Design, Technology, Architecture, Market, Business)
- Hand-edit any text field directly
- Use the AI Edit panel to rewrite sections
- Run the AI Scan
- Trigger logo generation
What they can't do is change ownership, invite additional collaborators, or delete the project. That stays with you.
For most use cases (designer reviewing the UX section, contractor reading the feature list, co-founder adjusting the business model) this access level is exactly right. They can engage with the spec as a live document, not just read a static export.
The logo generation counter is shared. The project allows up to 10 logo generation rounds total, across all editors. If you've already used seven, your collaborator has three left to play with.
Coordination patterns that prevent stepping on each other
The main thing to think through before you share is edit conflicts. Draftlytic doesn't have real-time collaboration in the Google Docs sense. If you and your collaborator are both in the Features tab rewriting things simultaneously, the last save wins.
A few patterns that work:
Designate sections. If your collaborator is a designer, have them own the Design tab and leave the rest to you. Practically speaking, you're never both in the same tab at the same moment if your focus is split.
Use the AI Edit prompt as a comment. When you apply an AI Edit, the prompt you typed shows up in the chat history. So "Changed this to reflect the pivot to B2B" stays as a breadcrumb. Not a formal comment system, but useful.
Freeze the spec before export. Before you export the PRD or the implementation plan for a contractor, agree with your collaborator that the spec is locked. One quick message, one last read-through together, then you export from that state. Trying to hand off a spec that's still being edited is how you end up building against a requirement that got changed three hours after the PDF left your outbox.
The AI Scan is worth running before you share a Draftlytic project at all. It finds the gaps that will cause the most confusion when someone else reads the spec cold. A shared editor who opens the project for the first time and finds a well-scoped features section, a clear audience, and explicit non-goals will ask far fewer questions than one who opens it and finds half-filled tabs. There's a detailed walkthrough of the Scan and the rest of the creation flow in the how to use Draftlytic guide.
When to share read-only access instead
Sometimes the person you want to share with doesn't need edit access. They just need to read the spec. A client who wants to approve scope. An advisor looking over the business model. A developer you're about to hire who's deciding whether the project is interesting.
For this, the right move is exporting the PRD as a markdown file and sending it. Draftlytic's export produces a single .md file with the full spec: overview, audience, features, design, stack, architecture, business model. It reads cleanly in any text editor, renders in GitHub, pastes into Notion, and opens fine in iMessage. No account required on their end.
The export is free and unlimited. You can re-export as many times as you update the spec.
The downside of sharing via export is the version problem mentioned at the top. Once they have the file, they have that version. If you change something significant, you need to send it again. For one-off reviews, that's fine. For ongoing collaborators who need to stay in sync, it gets tedious fast.
Use exports for: one-time reviews, client approvals, recruiting conversations, or anyone who only needs to read and has no reason to edit.
Use shared editors for: co-founders actively shaping the product, designers you're working with weekly, contractors who need to ask questions and leave comments.
Removing access when the engagement ends
When a collaborator's involvement winds down, remove them from the project. This is both tidy and practical: they no longer accumulate credit costs against your balance if they happen to run something, and you keep the project's edit history clean.
Removing a collaborator doesn't delete anything they did. Their edits stay in the spec. Their AI Edit prompts stay in the history. The project is exactly as they left it; they just can't open it anymore.
If the collaboration ends mid-spec and the project is still in progress, it's worth doing a read-through after they're removed. Sometimes a collaborator makes changes that make perfect sense in context but need a line or two of cleanup once they're no longer around to explain the thinking. Five minutes now saves you from explaining a confusing feature description to Cursor three weeks later.
The takeaway
Adding a collaborator to a Draftlytic spec is lower friction than most people expect. One invite, one accepted email, and they're reading the live document alongside you. The main thing to be deliberate about is the credit arrangement and edit coordination: your credits, shared access, no real-time conflict resolution. Set expectations upfront, split sections by ownership, and scan the spec before you share it.
If the engagement is temporary or the person only needs to read, the markdown export gets you 90% of the way there without any of the coordination overhead. Either way, the spec stays in one place, not scattered across a thread of screenshot attachments.