Alpha

For a long time the first time anyone outside the team saw a feature was the day it launched. Six months of designing, building and polishing, and then the first week of real use reveals that users wanted something else. By then almost nothing can be undone. The people and the months are already spent, so nobody inside the company is willing to say the direction was wrong.

Pagedeck learned this the expensive way. The team spent two months building comments on documents and released the whole thing at once. It turned out people didn't want comments; they wanted to see who had changed a document and when. The retro notes still carry Theo's line about wishing they had shown something rough in two weeks instead.

Alpha turns those two weeks into a rule. The build goes out with its incompleteness stated up front, which buys permission to show it far earlier than it would otherwise be shown. The arithmetic is simple: if the direction might be wrong, being wrong after two weeks costs two weeks, and being wrong after two months costs two months.

Not much works yet in an alpha, and that's the arrangement rather than a failure. The stage is defined by conditions everyone agrees to before the door opens.

1. Very few people use it. Usually the team that built it plus a few colleagues, and if it goes outside at all, fewer than ten people whose names you know. Never more than you can walk over to and ask about a problem directly.
2. Most of the feature is missing. One core path works and the rest is a button that does nothing, or isn't there at all. In the Pagedeck comments alpha you could post a comment, and that was it — no editing, no deleting, no notifications.
3. Data isn't guaranteed. Reshaping the underlying structure often means wiping what's been entered. So an alpha says in advance that anything put in here may disappear.
4. Screens don't match the design. Noa's work usually isn't attached yet, and what users see is whatever default styling the developer put in to get the flow running.
5. Feedback arrives as conversation, not as instrumentation. Not surveys, not dashboards — someone asking why a thing behaves that way. With this few users, asking is faster than measuring.

Announce those five and you have an alpha. Ship the same software without announcing them and you have an incident. The difference between the two isn't in the code at all — it's whether the people opening the door and the people walking through it agree on what they're looking at.

Leaving alpha isn't about finishing the feature. It's about reaching the point where someone from outside can get through it alone. If a screen only works when a teammate is narrating it, the feature is still in alpha. Three checks usually decide it.

1. The core path doesn't break. At least one person has to go from start to finish without help. If there's still a spot where an error forces a refresh, that spot is where outside users simply leave.
2. Entered data survives. You can't invite more people onto a structure that the next deploy is going to erase.
3. The direction question has an answer. Alpha exists to confirm, not to complete, so if nobody can yet say whether the feature is wanted, adding users only makes the same question louder.

Once those hold, the door opens a little wider. The usual next stop is closed beta, an invite-only trial where you choose the participants and any problem stays contained to a few dozen people. If the plan is to open it to paying customers first in exchange for their input, it goes to an early access program (EAP) instead — a similar number of users, but bound by a promise to give feedback in return for going first. Wider than that is open beta, where anyone can walk in, and removing the label entirely is general availability (GA).

"We're opening the alpha this week — just engineering and Mia for now."

Turning it on internally for a few people without telling anyone outside.

"That's an alpha. We said up front the data might not survive."

The lost records weren't an accident; they were a condition everyone agreed to.

"We haven't answered the direction question yet, so moving to beta feels out of order."

Settle whether the feature is wanted before adding more users.

At Pagedeck an alpha usually opens on a Thursday afternoon. Theo enables the feature for internal accounts only, and Mia posts five lines in the team channel saying what works and what doesn't. Those five lines act as the contract. Anything not listed there doesn't work, which means reports about it aren't collected. Skip that post and you get twenty reports of already-known bugs before lunch, with the feedback you actually wanted buried among them.

About a week in, Mia talks to each person who used it. She asks instead of surveying because ten people is small enough that asking is faster, and because watching someone stall in front of the screen says far more than a line in a form. What they were trying to do, and where they stopped, decides what gets built next. Grace looks at that and decides whether to widen the door. Deciding to drop the feature is a perfectly normal ending for an alpha.

The most common misreading is that alpha is a license to build sloppily. Since incompleteness has already been announced, quality standards feel suspended. But what drops in an alpha is scope, not craft. The one path that works has to work. If it keeps falling over, testers spend their attention filing bug reports instead of judging the feature, and the whole reason for opening early evaporates.

The other frequent mix-up is reading alpha as a version number. Outside the office the word does get used that way in software version strings, so the confusion is understandable. In practice alpha describes how wide the door is, not which release you're on. A product at version 1.4 can open a single new feature as an alpha, and one part of a product can sit in alpha while everything around it is generally available. Leave the confusion alone and meetings drift: one person means the whole product is early, another means one feature is open to a handful of people, and both say the same word.