General Availability

"We shipped it" used to mean a different thing to everyone at the table. The engineer meant the code is running in production. Sales heard that it can be sold. The customer understood they had bought a finished product. One sentence splitting three ways means nobody notices the disagreement until much later.

Pagedeck learned this the ordinary way. Sofia wrote document permission controls into an enterprise contract while Theo believed the feature was still a closed trial running for a handful of invited teams. The contract went out, the feature opened to everyone a month later, and in between there was no agreement about who would answer a support ticket about it.

General availability, usually shortened to GA, is the name for that boundary. Before the label, a feature can change shape or disappear without anyone having broken a promise. After it, the same support and accountability attached to everything else in the product attach here too. What matters is not how finished the code is but how far the promise has traveled.

The door is open to everyone, and the commitments around the feature now match the rest of the product. Four things separate this stage from the ones before it.

1. There is no admission requirement. Closed beta needed an invitation and early access needed an application and a review. Here anyone on the right plan can switch it on — no waitlist, no form. That also means the team loses its filter: up to this point it chose who got in and could pick patient customers, and from now on the least patient one arrives on day one.
2. Support arrives at full strength. Someone owns incoming questions, incidents enter the response rotation, and a failure becomes grounds for a refund. For enterprise customers the feature falls under the service level agreement (SLA), the service level promised contractually.
3. It appears in the docs and the price list. Help articles exist, the price list states which plan includes it, and changes go out through release notes. This is the point at which sales material and contracts may name it.
4. The room to change it shrinks. Up through open beta the team could rearrange the whole screen without consequence. After GA, a workflow that disappears one morning is an incident. The old path has to keep working for a while — that's backward compatibility — and anything being removed gets announced and retired on a schedule.

The fourth point is why teams hesitate longest at this door. Removing the label is less about opening a feature than about promising not to change it carelessly. A user who sees "beta" on a screen forgives a problem once; the same user on the same screen marked as generally available asks for a refund.

There is no wider box above this one. The ladder of stages ends here, so movement at this stage runs in only two directions: in through the door where the label comes off, and out through the door where the feature is retired.

On the way in, five things get checked.

1. The character of what's still broken, not the count. A slightly misaligned layout can ship. One defect that loses data or charges the wrong amount delays the date.
2. Support readiness. An owner for incoming questions and help articles have to exist first, along with answers to the questions everyone will obviously ask. Without them, Sofia answers the same question thirty times during the opening week and the answers differ each time.
3. Operational readiness. Monitoring that notices when something goes wrong, and a rollback path back to the previous version. A feature with no defined way back leaves the team with nothing to do when a problem appears.
4. Price and contract. Which plan includes it, and whether existing customers pay more. A customer on an annual contract who later hears that this feature is billed separately has a dispute, not a question.
5. Whether the load is survivable. A feature used by 50 teams in trial can see twenty times the usage once it opens to everyone, so the capacity gets verified before the door opens.

The way out is deprecation: announcing in advance that something will be removed and steering people away from it. Features aren't switched off quietly — the sequence is notice, a documented replacement, then a stated end date. It takes longer to leave this stage than to enter it, because leaving means unwinding a promise that entering created.

"Is this GA now, or still beta?"

Asking whether the feature can go into sales material and contracts yet.

"We're GA next week, so let's get the help docs and the price list aligned first."

The request is about the commitments that follow the deploy, not about the deploy.

"Let's push GA a month and keep running early access."

A judgment that support and operations aren't ready, rather than that the feature isn't built.

The meeting where Pagedeck opened document permission controls is typical. Theo reported that development had finished two weeks earlier and that the 50 teams in the trial had hit nothing serious. Mia's questions weren't about the code. Where does a customer go when a bad permission setting hides their document, who picks up that ticket, and is the way to undo it written down anywhere?

Two of the three answers were missing, so GA moved by two weeks. The rule Grace stated in that meeting stuck: Theo answers whether the feature works, and the people who take the tickets answer whether the label comes off.

The most common reading is that general availability means the feature is finished. Beta sounds unfinished, so its opposite sounds complete. But features ship into GA with known problems and keep getting fixed afterward. What changes is the level of commitment, not the level of completeness. Teams that treat the label as proof of completion hold it back until every item is closed, and customers spend a quarter unable to use something that already works. The list of open items never empties on its own, so the date arrives only when somebody decides the remaining ones are survivable.

The opposite mistake also shows up: reading GA as the day the work ends. It usually lands near the end of development, so it looks like a finish line. In practice it's the day tickets start arriving and the feature joins the incident rotation. In earlier stages a problem could be apologized for and fixed; here refunds and contracts are attached. Book the next project straight after and nobody is left to answer the first week's questions.