The web alpha was almost ready for a small group of real people.
The mobile application had carried most of the visible product work. A web version introduced a different set of expectations. People would use a keyboard and a larger screen. They could open several tabs, follow links differently, and compare the experience more directly with other work software.
The team proposed writing a release document before opening access. The document would identify the main paths to test, the known limits, and the place where observations should be recorded.
An alpha label described the state accurately. The point was to learn whether the core flow held together on the web, not to present every screen as complete.
The test plan needed to distinguish a defect from an unfinished area. A broken button, lost session, or failed connection required a different response from a feature that had intentionally not been built yet.
It also needed a starting state. Testers should know whether to create a new account, use an invitation, connect an existing service, or begin with prepared data. Without that instruction, every person could test a different path and produce feedback that was difficult to compare.
The private record includes the tester list and internal product scope. Those details stay out of this article. The size of the group and individual feedback are not public.
The public-safe event is the preparation of a bounded web test. Goodword was expanding beyond the mobile build, and the team wanted a written way to verify what the first web version could do.
The release document was still a proposal. The alpha was close enough that test instructions, known limits, and feedback handling had become part of the product work.