Let them in.Lose nothing.

Beta readers and editors want different things from you

A beta reader is there to read the book the way a reader would: to tell you where they got bored, what confused them, which character they stopped believing. The best beta readers see a manuscript that looks like a book, not a workshop. They don’t need your notes, your bible or your plans, and showing them those can colour how they read.

An editor needs the opposite. A developmental editor wants the structure, the arcs and the reasons behind them. A line editor wants to get into the sentences. Both need to change things, and you need to see exactly what they changed and keep the right to say no. Treating both groups the same way, one shared file for everyone, is where most of the confusion starts.

A role for each person

Authrot has six roles: owner, admin, editor, writer, commenter and viewer. An editor writes, edits the story bible, the rules and the formatting, and can restore old versions. A writer drafts with the assistant but leaves the bible to you. A viewer reads only. Commenters and viewers get no AI at all, so a reader never spends anything on ideas they can’t act on.

Invite someone by email, with a link that works only for that address. Nobody can grant a role higher than their own, and you can change or remove a person’s role whenever you like. Every project checks the role before anything is read or changed.

Think about what each person actually needs before you choose. A line editor working through the prose needs the editor role. A trusted first reader who only has to read the draft is best as a viewer, where nothing they do can change the text. A co-author drafting chapters of their own might be a writer. Starting with less access and raising it later is easier than the other way round.

• Owner: everything, including publishing and handing the project over
• Admin: everything but publishing and the owner’s settings, and manages people
• Editor: writes, edits the bible, rules and formatting, restores old versions
• Writer: writes, with the assistant
• Viewer: reads only

Editing together, live or on a branch

Some editing works best in the same room. With live co-editing, you and your editor can both be in a chapter, each seeing the other’s cursor and every keystroke as it happens. That suits the scenes where a quick back-and-forth beats a page of written notes: a fight that doesn’t flow, a reveal that lands too early.

For a longer pass, an editor can work on a branch of their own, so their changes don’t appear in your working draft while you’re still writing. When they’re finished, merging the branch shows you what will change first, and asks you about each real conflict instead of picking for you. Afterwards, recent-edit marks in the margin show what changed lately, with a word-by-word diff a click away.

If an editor uses the assistant, they run it on their own credits or their own model key, and their conversations with it are private to them, as yours are to you. The assistant’s edits land without stepping on anyone’s typing. If you’d rather the AI stayed out of the project while it’s with an editor, AI blackout turns it off for the whole project.

No change is final

The fear of handing over a manuscript is partly the fear of losing the version you had. In Authrot every version of every document is kept, and every change to the plan and the bible too, in one History feed. Preview any version, diff it against the one before, and restore it. Open a commit and undo just the field you want.

Before you send the book out, press Ctrl/⌘+S to save a named version (“Before Sam’s line edit”) so there’s an obvious place to come back to. If an editor’s change to chapter twelve was right and their change to chapter thirteen wasn’t, you keep one and roll back the other, without asking them to redo anything.

Giving beta readers the book, not the workshop

For beta readers you have two routes. Add them to the project as viewers, and they can read the manuscript but change nothing. Or publish the chapters unlisted, shared by link only, and they read on Authrot’s reader pages: clean chapter pages in your chapter styling, with their own typeface, size and light, sepia or dark. They see your pen name, never your real name or email.

Authrot doesn’t have margin comment threads, so collect beta readers’ answers however suits you and them: a shared document, an email, a call. What matters more is what you ask. Vague requests (“what did you think?”) get vague answers. Specific questions get usable ones, and asking the same few questions of every reader lets you see where their reactions agree, which is where the real problems usually are.

• Where did you put the book down, and why?
• Which character did you stop believing, and when?
• What did you expect to happen that didn’t?
• Was anything confusing about who knew what?
• Which scene would you cut first?

When the notes come back

Feedback arrives in a heap, and the temptation is to fix everything at once. Resist it. Sort the notes first: what several readers agreed on, what one reader felt strongly about, and what is simply taste. Structural problems come before line problems, because there’s no point polishing a scene you may cut. A branch is a good place to try a big structural change without touching the draft your editor is still working in.

As you revise, the story bible and the checks list keep the fixes honest. Move a reveal two chapters earlier and, once the chapters are read again, the record of events shows the chapter where it now happens, so you know where the later scenes need checking. Rename a character a reader kept confusing with another, and the rename runs through the whole text with a preview. When the revision is done, save a version, and the book is ready for the next round of readers.