VoidFLag - what feature flags should have been from the start

#webdev #programming #productivity #devops

Imagine this.

You get a message from your team saying "something broke in production."

You open your dashboard, flip a toggle. Done. Back to work.

A few minutes later, another message. "Still hitting production."

But you already disabled it.

So you start digging. Scrolling through logs. Searching. Wasting time.

Everything looks fine. So you go deeper, into the code itself.

And then you find it.

The flag was never turned off. Because someone typed "checkout flow v2" instead of "v2 checkout flow". And the system accepted it without a second thought. No error. No warning. Nothing.

The tool built to save you from late-night deploys just handed you one.

Ironic, right?

That's why I built VoidFlag.

VoidFlag is a schema-first approach to feature flags. You define your flags once, and from that moment, everything is typed. No loose strings. No typos. No surprises.

Because your flags live in your code, mistakes don't reach production. They don't even compile.

Your editor already knows every flag you have. Autocomplete, validation, errors caught before your code runs. When something changes, it shows up in your Git history, not buried in a swarm of logs.

How it works

The workflow is CLI-driven:

Run vf dev to spin up a local server during development
Run vf push to take flags live
One command generates a typed client for your entire stack, so your whole team works from the same contract

The dashboard is still there, for real-time control. But by the time you reach it, your codebase is already in sync.