Why Customers Never See Our Internal Phase Numbers

Every engineering team develops its own vocabulary. Work is organized into phases, waves, sprints and deliveries. Checklists have counts. Projects have code names. That language is useful inside the team; it helps people coordinate and track progress.

Outside the team, it is noise at best and confusion at worst. A customer who reads "Phase 4 features" in an admin screen wonders whether they are missing phases one through three. A help article that mentions "Wave 2 importer" suggests there is a better version somewhere they cannot reach. So we have a firm rule: internal delivery labels never appear in our product.

Where the rule applies

The rule covers every place a customer might read our words:

• Admin screens, labels, descriptions and empty states
• Help Center articles and in-app help
• Answers from our help assistant
• API descriptions and developer documentation
• Emails and notifications
• Marketing and product pages

In each of those places, we describe the current capability, the access it requires, its cost and whether it is available or on hold. We do not describe how or when it was built.

What to say instead

A few examples show the difference:

• Instead of "Phase 2 live classes," say "Live classes," and if the feature is not available yet, say so plainly.
• Instead of "the new Wave 3 import flow," say "Import from WordPress."
• Instead of "47 of 55 checklist items complete," describe what the feature can do today.
• Instead of a code name, use the product's real name.

The customer-facing version is almost always shorter and clearer.

Honest about what is not ready

Avoiding internal labels does not mean hiding limitations. If a feature is on hold, the honest description says it is not available yet, without referencing internal plans. If a feature requires a specific plan or approval, the description says that. Customers deserve accurate information about what they can do today, expressed in their language.

Internal records keep their labels

None of this means our internal records lose their structure. Engineering handoffs, roadmaps and delivery notes keep their phase names, counts and dates, because those are useful for the team. Historical identifiers in old links also remain where changing them would break things. The rule is about the boundary: internal language stays internal.

Help content gets extra care

Help articles are a common place for internal language to leak, because they are often written by the people who built the feature. Before help content is published or updated, it is reviewed for this specifically, alongside accuracy checks. Since our help assistant shows reviewed articles directly to customers, a leaked label would travel quickly. You can read about that system in help answers grounded in reviewed articles.

The same principle for product names

Customers should also see consistent product names. Internally, a product may live in a folder with a short technical name. Publicly, it has its real name, and we use that name everywhere a customer might see it. Mixing the two makes software feel unfinished.

A broader habit of plain language

This rule is part of a wider commitment to plain language. Settings say what they do. Errors say what happened and what to try next. Confirmations explain consequences. Our design standard for admin screens asks for the same clarity, which we describe in one design standard for every admin screen.

A quick test for any screen

A simple test catches most internal language: read the screen as if you had never met the team. Does every label make sense without knowing the project's history? Does any word require an explanation that only an insider could give? Would a new customer understand what each button does and what it costs? If the answer to any of these is no, the words need work.

We apply the same test to error messages, which are often written in a hurry by the person who wrote the code. "Validation failed for tenant site binding" means something to an engineer. "This website is not connected to your account yet" means something to a customer.

Consistency builds confidence

When the same feature is called the same thing everywhere, in the menu, the page title, the help article and the email, customers learn it once and trust it. When names vary, people wonder whether they are looking at different features. Keeping a short list of approved product and feature names, and using it everywhere, is a small habit with a large effect.

Frequently asked questions

Why avoid phase or version labels in software interfaces?

Internal labels confuse customers and suggest missing features. Describing what a feature does and whether it is available is clearer.

How do you describe a feature that is not ready yet?

Plainly: say it is not available yet, without referencing internal plans or phases, and avoid implying a date unless one is committed.

Do internal engineering documents still use phases?

Yes. Internal records keep their structure and labels. The rule only applies to customer-facing text.