From beta feedback to the next release
Plot is in early access, which means the gap between a writer hitting a wall and us seeing it is hours, not quarters. That feedback loop is the best thing about building in the open. It is also a trap: if you ship whatever the loudest request asks for, you end up with a pile of features and no product. Here is the lens we use instead.
We sort feedback by what it reveals, not what it asks for
A feature request is an answer. Our job is to recover the question. When a writer asks for a button, the button is their proposed solution to a problem they're feeling — and often the problem is real while the proposed button is not the best fix. So every piece of feedback gets read twice: once for the literal ask, once for the underlying friction it points at.
- What is the writer actually trying to do? Not the feature — the goal behind it.
- How often does this come up, across how many different writers? One vivid request is a data point; five quiet ones in the same area are a pattern.
- Does the fix fit the substrate, or fight it? The best changes fall out of version control, structured documents, and skills. The ones that fight that foundation are warning signs.
- What does it cost the rest of the product? Every feature is also surface area — something to maintain, explain, and keep out of everyone else's way.
The substrate is the filter
Inkwell is built on a specific foundation: documents are structured data, history is a sequence of immutable save points, and AI operates as reviewable skills. Requests that compose naturally with that foundation are cheap and durable. Requests that require working around it are expensive and fragile — and usually a sign that either the request or our model is in the wrong shape.
Concretely: "let me compare two table-read drafts side by side" composes — it is just a diff between two save points, which the substrate already makes precise. "Let me freely edit the formatted PDF and sync it back" fights the substrate, because the PDF is a rendering of structured data, not the source of truth. Same energy from the writer; very different cost and durability. We say yes quickly to the first kind and slowly, carefully, to the second.
What that ordering looks like right now
You can watch the filter work by reading the roadmap in order. The structured editor and screenplay parser are live — the foundation everything else stands on. Version control comes next as it firms up: save points, draft lines, semantic change tracking, and incorporate. The AI skills that operate on those structured drafts — dialogue pass, continuity check, character runner — build on that same substrate rather than beside it. Production workflows (locked pages, revision colours, A-pages) come after, and Canvas — the general-purpose editor — sits beyond Plot on the same platform. Each stage falls out of the one before it, which is exactly the point: the order is not a marketing sequence, it is a dependency graph. The live status for each of those lives on the About page, so it stays current as things ship.
Shipping cadence over big-bang releases
Because the team is small and the loop is tight, we favor frequent, narrow releases over rare, sweeping ones. A narrow release is easy to reason about, easy to roll back, and easy to connect to the feedback that motivated it. It also keeps us honest: if a change can't be described in a sentence and shipped in a week or two, it usually wants to be broken into smaller pieces first.
That is the whole method, and it is deliberately unglamorous. Read feedback for the question, not the answer. Favor changes that fall out of the foundation. Ship small, ship often, and keep the surface area honest. It will not produce the longest feature list in screenwriting software. It is meant to produce a tool that still makes sense to use a year from now.