Why I Built Feature Toggles Into the Bracket App

Sometimes the feature isn’t for the user.

It’s for us—the system operators, the maintainers, the ones who have to keep the app online when the fire starts. Or steer quietly into a beta when the paint’s not dry yet.

This is one of those features.

The Instinct

I’ve been moving fast with the bracket app—too fast, maybe. New features like theme management, demo mode, admin controls—they all assume the world is working exactly as planned.

But what happens when something breaks? Or when I want to test a feature in production, but only for a few users?

That’s where feature toggles come in.

Not just a kill switch. A framework for conditional execution, built into the bones of the system.

I jotted down the first five immediately:

• Disable new registrations
• Disable admin site access
• Disable tournament creation
• Disable demo mode
• Disable custom theme creation

No whiteboard. No backlog grooming. The need was obvious.

Design Goals

This wasn’t going to be a messy if (isProd) hack job. I needed:

• A Supabase-backed toggle system with environment and role filtering
• A way to cache and evaluate toggles client-side
• A hook like useFeatureToggle() to keep React declarative
• No UI yet—CLI or Supabase-first is fine
• RLS enforcement so only super_admin can flip switches

With that, I dropped the prompt to Kilo.

Laying the Foundation

This feature isn’t just about control. It’s about agency—for the system itself and for the operators behind it.

To test safely. To react fast. To gatekeep with intention.

I’m not just building apps. I’m building the switches that run them.

What’s Next

Once Kilo’s plan lands, I’ll review for alignment, add toggle enforcement + caching, wire them into routes, actions, and guards, and ship them quietly—off by default.

And from there? Maybe per-tournament experiments. Maybe staged rollouts by role. If the bracket app is turning into infra, this is the control panel.

I’m still figuring out the right granularity—how many toggles are too many, and at what point the system becomes harder to reason about than the features it’s protecting. But the core idea feels right: operational control shouldn’t be an afterthought.