When the website sprint finishes, beta access reopens. We’ve been answering enough questions about what beta means, what it costs, and what we expect from testers that it’s worth writing it down in one place.
This post is that.
Short version: beta is small, structured, and deliberate. We’re capping the cohort at 25 people absolute maximum, with a starting cohort closer to 5 to 10. We’re picking testers based on fit, not first-come. The deal goes both ways — we give beta testers something real, and we ask for something real in return.
Here are the details.
The cohort is intentionally tight
Every other software project that’s gone wrong in the same space has gone wrong by trying to onboard hundreds of beta testers at once. The pattern is predictable: bug reports pile up faster than fixes ship, the dev burns out trying to keep pace, the testers feel ignored, the product gets a reputation for being unresponsive before it’s even launched.
We’re not doing that.
A small cohort means each tester gets actual attention. When you file a bug, we read it. When you report something odd, we look. When you say a feature is missing or confusing, we have time to think about whether you’re right and how to fix it before the next feature lands. That kind of responsiveness scales down well and up badly. We’d rather have ten testers with a real channel to the dev than a hundred testers shouting into a queue.
The exact starting size is between five and ten people. We may add testers later if the rhythm is right. We won’t exceed twenty-five. That ceiling exists because Storyverse Author is built by one person, and one person can pay attention to twenty-five testers. Twenty-six would tip the balance.
What you get
If you’re picked for beta, here’s what’s on your side of the deal.
Free access during beta. No charge for the duration of your beta participation. The full app, all features, all storyverses, all tools.
The betaauthor subdomain. Beta testers don’t share the production database with the open membership. You get betaauthor.storyversesystems.com, with its own copy of the app, its own feature flags, and updates that ship to you before they ship to anyone else.
Direct line to the dev. Bug reports, feature requests, “is this broken or am I misreading it” questions — the channel is direct, and the response time is measured in days, not weeks. Beta isn’t a help desk relationship. It’s closer to a working partnership.
Real influence on what ships next. The roadmap isn’t a finished document. It’s a working list, and beta tester feedback moves items up and down it constantly. If three testers tell us the same thing is missing, that thing usually gets built. Beta is when the product is most malleable.
Custom Structures rolling out mid-beta. The most-requested feature on our list — letting members build their own plotting methodologies on top of the 19 we ship — lands during beta. Beta testers see it first. The version they help shape is the version that becomes the public release.
What we ask in return
The other side of the deal isn’t long, but it’s not zero either.
Use the app. Not nightly, but regularly enough to have opinions. A tester who logs in twice in three months can’t tell us much. A tester who’s actively writing inside the app every week can tell us everything.
File feedback when something’s wrong. A bug report doesn’t have to be polished. It has to exist. “I tried to do X, this happened instead, here’s what I expected” is the format. Two sentences is fine. The point is to flag it while it’s fresh.
Be patient with bugs. Things will break. Some will be embarrassing. Beta is when we’re allowed to break things in front of you because the cohort is small enough that we can fix them quickly. We expect bugs. We expect tester reactions to bugs to be measured.
Tell us what’s missing. This matters as much as bug reports. The features that get added during beta are the features testers asked for. If you sit in the app for three months and never tell us what you wished it could do, we won’t know to build it. Speak up.
Honor the small-cohort agreement. Beta access is for you. Don’t share login credentials. Don’t post screenshots of broken states publicly while we’re fixing them. Standard early-access etiquette. We trust testers to know what’s appropriate without a long policy document.
How the application works
When the website sprint finishes, the newsletter announces that beta is open. The application form is short — name, what you’re working on, why you want in, what you’d want to test. We read every application. Selection is based on fit, not first-come-first-serve.
“Fit” means a few specific things. Active writers building or planning serious work. Writers whose use of the app would teach us something about how it performs in real conditions. Writers who can articulate feedback. Writers we’d actually want to talk to.
We’re not optimizing for the loudest applicants or the most credentialed ones. We’re optimizing for the cohort that will help us make Storyverse Author better, faster.
What happens when beta closes
Beta isn’t permanent. When the cohort has helped us harden the next round of features, beta closes and the betaauthor subdomain folds into the public release flow. Testers who were active and helpful during beta are remembered — there will be a thank-you mechanism, the specifics of which we’ll announce closer to the date. We won’t forget the people who helped us get there.
After beta, the next milestone is the public reopening. The features that landed during beta are public, the bugs the cohort caught are fixed, and the website that was built during the freeze is the front door to it all.
Where to follow along
Three places we’ll announce beta opening:
- The Story Architect newsletter (one email a week, Thursday mornings)
- This blog, under the Platform Updates category
- The member dashboard, for anyone already inside
If you’re interested in beta, the newsletter is the right place to be when the announcement happens. The application window will be short, and the cohort will fill quickly.
We’re looking forward to opening the doors.
