Holding Unfinished Features Back Until They Are Truly Ready

By Sharon C
Nov 08, 2025 4 min read 8 views
Holding Unfinished Features Back Until They Are Truly Ready
Shipping code and releasing a feature are different decisions. Here is how we hold unfinished modules back completely, not just from the menu, until they are ready.
Share:

Software is often built in pieces. A new module may be partly complete for weeks while other parts are finished, reviewed and tested. During that time, its code lives in the same platform as everything else, because that is how small, safe changes work. The question is how to keep customers from stumbling into something that is not ready.

Our answer is a hold: a deliberate decision that a feature stays closed until an owner approves releasing it. Holds are not just about hiding a menu link. A held feature is closed at every door.

Shipping is not releasing

We separate two decisions. Shipping means the code is in the platform, deployed through the normal pipeline. Releasing means customers can use the feature. Keeping them separate lets us build in small steps without exposing half-finished work.

This also means a feature can be tested on the real platform by our team before customers see it, which often reveals problems that test environments miss.

Closed at every entry point

Hiding a module's menu item is not enough, because people can reach pages in other ways: a bookmarked address, a link in an old email, an interactive component on a dashboard. When a module is held, we close it everywhere:

  • Its menu items and sub-pages are hidden
  • Direct visits to its pages are refused
  • Its interactive components refuse to load
  • Its dashboard widgets and tabs do not appear
  • The hold applies across every plan, every custom domain and even when our support staff are working inside a customer's account

That last point matters. Support access should not become a side door into held features.

Quote card: Code can be finished long before a feature is ready. Releasing it is a separate, deliberate decision.

Existing data is preserved

Holding a feature does not delete anything. If some records already exist, perhaps from early testing or from a feature that was paused after launch, they stay intact while the hold is in place. When the feature is released again, they are still there. Holds control access, not data.

Holds have owners and conditions

Every hold has an owner who decides when it ends and a description of what must be true first: certain checks completed, a provider configured, a policy reviewed or an approval given. Those conditions are written in the handoff for the feature. Nobody lifts a hold because it seems ready; the owner lifts it when the conditions are met.

Holds also do not authorize anything on their own. A held module's owner may continue building, but actions like connecting accounts, sending messages or spending money still require their own approvals.

Examples of what we hold

Holds are used for features that carry real risk if released early. A module that sends messages on people's behalf stays closed until consent, scheduling and account connection handling are fully verified. Text messaging stays off until registration and opt-out handling are complete, as described in consent first. Website test payment modes stay held while the accounting and recovery paths for them are being finished.

Honest descriptions while held

When customers ask about a held feature, the honest answer is that it is not available yet, without internal plans or dates that are not committed. We do not show teasers for features that might change significantly before release, and we never describe internal stages to customers. You can read more in why customers never see our internal phase numbers.

The benefit of patience

Holding features takes discipline, especially when something is nearly done and people are eager to use it. But the cost of releasing too early, whether a privacy problem, a billing mistake or a confusing half-feature, is usually far higher than the cost of waiting a little longer. Holds let us build openly and release carefully.

Frequently asked questions

What is a feature hold?

A feature hold keeps a built or partly built feature closed to customers until an owner approves releasing it, even though its code is deployed.

Is hiding a menu item enough to disable a feature?

No. A held feature must also refuse direct page visits, interactive components and dashboard widgets so it cannot be reached another way.

Does holding a feature delete its data?

No. Holds control access only. Existing records are preserved until the feature is released again.

Comments (0)

No comments yet. Be the first to share your thoughts!