A feature request can sound like a request for a new option: a new display mode, a new kind of setting, a new workflow, a new screen. The first instinct is often to add a parallel branch beside the existing ones.

That is sometimes right. But it is worth asking a different question first: what existing capability is this request really asking us to expose?

In this case, the request was to make a title feel more distinctive. The first proposal was a separate title style. The better answer was to use the title style that already existed and expose the missing controls that made it useful.

Find the pattern before you build a branch

Mature products often have more capability than their visible interface suggests. A setting may already have a shared rendering pattern, a standard way to save changes, a rule for when it should appear, and a consistent way to recover from a mistaken edit. The product does not necessarily need a new subsystem. It may need one well-placed control.

Before designing a parallel feature, look for:

  • a nearby control with the same data shape;
  • an existing save path that already validates and persists similar settings;
  • a visibility rule that already distinguishes applicable from inapplicable contexts;
  • a tested rendering or interaction pattern that users already recognize; and
  • a documented owner and change process for the capability you are extending.

Reusing a pattern is not an excuse to skip review. It is a way to inherit behavior that has already been tested and understood, then verify that the new use belongs inside its boundaries.

Reuse the gate, not just the presentation

The strongest part of an existing pattern is often invisible. A control may appear only when it applies, remain unavailable when it could confuse or harm a user, and save through a validated path. A parallel feature must recreate all of those decisions. An extension can inherit them when the shared condition truly represents the same product rule.

That distinction matters. Do not copy a condition merely because it is convenient. Read what it protects. Confirm the new control has the same applicability, accessibility, authorization, data-handling, and lifecycle requirements. Test a negative case: a place where the control should not appear or should not take effect. A feature is not consistent just because it looks consistent in the happy path.

Test away from real customer impact

A familiar interface can make a change feel low-risk when it is not. Before a demonstration or release, use an authorized non-production environment or representative test data. Confirm that the change saves correctly, appears only where intended, preserves existing content, and can be reversed. Do not treat access to live customer data as a substitute for a test plan.

Record what changed, who approved it, what was tested, and how to recover if the feature behaves unexpectedly. That makes a small extension easier to trust than a large new branch with unclear boundaries.

Why less code can mean more coherence

A parallel option usually brings a parallel set of problems: its own visibility rules, persistence logic, rendering behavior, documentation, support questions, analytics, and eventual migrations. Each is another place for the product to drift.

When an existing pattern genuinely fits, the new behavior benefits from the same semantics as its neighbors. Users encounter it where they expect it. Maintainers can reason about it through the same model. The product gains capability without teaching everyone a second way to accomplish the same job.

The takeaway

When a request arrives, do not begin with “what new thing should we build?” Begin with “what part of the product is already close, and what is missing from its public surface?”

A new branch is justified when the underlying job, risk, ownership, or lifecycle is genuinely different. Otherwise, exposing the right control on a trusted path can be the more elegant feature: less duplication, clearer behavior, safer change management, and a product that feels like it grew from itself rather than beside itself.