I spent the last few weeks building ToggleTown, a feature flag platform for developers. Not because the world was asking for another one, but because I kept hitting the same wall: feature flags are either expensive per seat or a chore to self-host.
LaunchDarkly charges per seat and gates the interesting features behind Enterprise. Unleash wants you to run its infrastructure. Flagsmith sits in between but still feels heavy for a two-person team. I wanted something plain: create a flag, toggle it, evaluate it in code with no latency, pay a flat fee. So I built it. Here is what I actually learned.
Solve your own problem, then check if it generalizes
Every flag tool I tried had the same failure mode: the pricing punishes a growing team. Add two engineers and your bill jumps by $60/month for what is, underneath, a config store with a good UI and an evaluation SDK.
My whole thesis fit in three lines:
- A free tier that is actually usable for a side project, not a 14-day clock.
- A flat monthly price for real teams — unlimited seats.
- No per-seat pricing, ever.
Not a revolutionary insight. But most teams do not need 90% of what an enterprise flag platform ships. They need boolean toggles, percentage rollouts, and a few targeting rules. The rest is surface area.
The stack
I picked what I already knew and what moves fast:
- Backend: Node.js, Express, Prisma, PostgreSQL, Redis for caching.
- Dashboard: React, Vite, Tailwind, React Query.
- SDKs: JavaScript, React, Node.js, Python, Go.
The load-bearing decision: every SDK evaluates flags locally. The SDK fetches the flag config once, keeps it in memory, and polls for changes. When your code calls getBooleanFlag('new-checkout', false, ctx) there is no network round-trip — it is a map lookup. Flag checks tend to sit in hot paths, and you do not want a request per page load. (More on that trade-off in a separate post.)
What actually took the time
The core was quick. Flag CRUD, environments, auth — ordinary Express and Prisma work. Roughly 70% of the time went to everything around it.
Five SDKs in five languages
Each one needs initialization, background polling, graceful shutdown, error handling, and its own copy of the targeting-rule evaluator. The Go SDK meant learning Go’s sync.RWMutex patterns; the Python SDK needed a background polling thread. Every language has a slightly different idiom for the same three concepts, and the behavior has to match exactly or a flag evaluates differently depending on which service checks it.
The targeting rules engine
“Enable this flag where email ends with @acme.com and plan is pro” sounds trivial until you support nested AND/OR groups, string operators, and percentage rollouts based on consistent hashing so the same user always lands in the same bucket. Then segments on top of that.
Billing and limits
Subscriptions, checkout, plan-limit enforcement, usage counters in Redis that flush to Postgres on a schedule, promo codes. The promo code system alone ate a full day.
The production tax
Prometheus metrics, structured logs, health checks, tiered rate limits, circuit breakers on webhook delivery. The work you skip in a prototype and cannot skip in production.
Features worth building
A flag health dashboard
The feature I am most attached to. Every team accumulates stale flags — you ship a feature, ramp it to 100%, and never delete the flag. Six months later there are fifty flags and nobody knows which are safe to remove. ToggleTown classifies each flag as active, stale (untouched for 30+ days), or ready to remove (100% everywhere for 30+ days), with a per-project health score and a weekly digest. Read the best-practices post for how to keep the list short in the first place.
An MCP server
A bet on where development is heading. The MCP server lets AI coding assistants create, toggle, and evaluate flags without leaving the editor. Small edge today; bigger as AI-assisted development becomes the default.
Experiments in the same product
Most tools treat A/B testing as a separate SKU. ToggleTown keeps experiments on the same platform — define variants, allocate traffic, track events through the SDK, read significance — with the same API keys and no extra bill.
Mistakes I made
- Building five SDKs before validating demand. I should have launched with JavaScript and Node, then added the rest on request. Five SDKs is a maintenance surface that is hard to justify before you have users.
- Over-engineering billing. Plan limits, usage tracking, promo codes, and upgrade-request emails — all before a single paying customer. “Email me to upgrade” would have covered the first hundred users.
- Writing comparison pages late. People searching “LaunchDarkly alternative” or “Flagsmith alternative” are the highest-intent traffic there is. Those pages should have existed on day one.
What is working
The free tier carries acquisition — no card, enough flags to actually build something. The upgrade is natural: you hit the limit, you have already integrated the SDK, and $29/month is an easy yes. And the developer experience is the moat. Account to first flag in about five minutes. If time-to-value crosses ten minutes, developers leave.
If you use feature flags — or keep meaning to — try ToggleTown. The free tier is a permanent plan, not a trial, and I read every piece of feedback.