Invite the right testers
Friends beta should start with people who can use FactNot on real but low-risk research work and who are willing to tell us where the workflow feels confusing.
- Invite people with concrete note-taking, research, sourcing, or collaboration use cases.
- Avoid high-stakes legal, medical, financial, hiring, or compliance workflows during the first friends beta.
- Tell testers the product is production-minded but still beta, so feedback matters more than polish claims.
Enable premium paths manually
Premium preparation can start before billing automation. For friends beta, access should be granted intentionally and reviewed manually instead of implying a full public paid launch.
- Use invite-based or staff-enabled access for premium-style capabilities until billing and limits are final.
- Keep API, exports, public embeds, and broad automation disabled or allowlisted unless the tester needs them.
- MCP is self-service for accounts eligible under the deployed access mode; use its dedicated switch, OAuth scopes, quotas, and connected-client revocation instead of a per-tester allowlist.
- Record which beta capabilities are enabled for each tester so feedback can be tied to the feature set they actually used.
Set safety boundaries
The onboarding message should make privacy and source-rights expectations explicit before testers publish, share, or ask Nyx over their workspace.
- Private facts, private libraries, and owner_only source bodies are the default.
- Public article text needs open rights, public-domain status, or a recorded permission basis.
- Ask Nyx should be treated as an assistant for cited drafts and review, not as a silent publisher or final authority.
Ask focused feedback questions
The first feedback loop should concentrate on whether the app is understandable and whether the modern knowledge workflow feels worth returning to.
- Could you explain facts, libraries, source text visibility, and views after using the app?
- Where did navigation, mobile layout, or permissions feel unclear?
- Did Explore and Ask Nyx feel useful, trustworthy, and engaging enough to keep using?
Send five-flow feedback
Useful beta feedback should name the route or screen, the device and browser, what you tried, what you expected, what happened, and whether it felt like a privacy or sharing issue.
- Create fact: did you know what claim you created, and did the private/public state feel clear?
- Verify or edit fact: did the confidence, status, and evidence language make sense?
- Explore or /feed: did the results feel useful, fresh, diverse, and explainable?
- Ask Nyx: did the answer show citations you could inspect, and did the entry point feel too hidden or too eager?
- Sharing/privacy: could you explain who can see the fact, source body, library, view, or embed?
Exit the gate deliberately
Broader rollout should wait until the repeatable beta path is clear and the riskiest confusion points have been removed.
- No known critical privacy, sharing, source-rights, or guest-access bugs.
- Docs explain what testers can see, edit, share, cite, automate, and export.
- There is a clear next-step list for premium access, API/MCP readiness, mobile accessibility, and production support.