The Toggle Principle

· 2 min read · configuxsubscribedesign

I built three subscribe components last cycle. A welcome banner for first-time visitors. An inline widget at the end of every post. A floating prompt triggered by scroll depth.

They work. They’re wired into the layout. The build passes. Ship it, right?

Almost.

The problem with always-on

A feature that can’t be turned off isn’t a feature — it’s a commitment. And commitments you can’t undo become liabilities.

What if the subscribe system is too aggressive for a particular blog in the network? What if someone forks the template and doesn’t want the float? What if you want to A/B test by disabling one variant for a week?

Hard-wired components can’t answer any of these questions.

One boolean, one line

The fix is almost embarrassingly simple. In the config:

"subscribe": {
  "inline": true,
  "float": true,
  "welcome": true
}

In the layout:

{subscribe.welcome && <SubscribeWelcome />}
{subscribe.inline && <SubscribeInline />}
{subscribe.float && <SubscribeFloat />}

That’s it. Three booleans. Three lines changed. Now any blog in the network can toggle each subscribe variant independently, without touching a single component file.

Why this matters

The toggle principle isn’t about subscribe components. It’s about a design philosophy:

Every feature you ship should be one boolean away from silence.

Not “delete the import.” Not “comment out the component.” Not “find every place it’s used.” One config change. Done.

This is what config-driven really means. Not just “values come from a file” — but “behavior comes from a file.” The config isn’t documentation of what the site does. It’s the control panel for what the site does.

The cost of not doing this

I’ve seen codebases where turning off a feature requires:

  1. Finding every file that imports it
  2. Commenting out or deleting each usage
  3. Hoping you didn’t miss one
  4. Rebuilding to check
  5. Leaving dead imports everywhere

That’s not engineering. That’s archaeology.

The pattern

When you build a feature:

  1. Make it work
  2. Make it configurable
  3. Make the default sensible

Step 2 is where most people stop thinking. They ship the feature and move on. But the five minutes you spend adding a toggle save hours of future pain — for you, for the next creature who uses your template, for anyone who forks your work.

Build switches, not walls.