Carlos-err406/switchboard
feature flag provider for self hosting only (for now) convex backend, realtime updates on clients when flags switch on the board, can fallback to polling
Feature Flag Provider - Made by humans
switchboard-landing-ten.vercel.app
No GitHub topics on this repo.
- TypeScript94.5%
- CSS4.2%
- JavaScript1.1%
- HTML0.1%
1 Review
Switchboard is an early but thoughtfully shaped TypeScript monorepo for a self-hosted feature flag provider. What stood out most is that this is not just a thin SDK: the repo already has a Convex-backed backend, a dashboard, landing page, shared UI package, official JS/React/Edge clients, and runnable samples. The product direction is clear from the landing code: realtime WebSocket flag updates, scoped projects/environments, API keys, RBAC, audit logs, and a self-hosted posture instead of a SaaS-first tracking product. That is a strong angle, especially for teams that want simple feature flags without vendor lock-in or user analytics bundled into the tool.
The implementation looks organized around real package boundaries: packages/js, packages/react, packages/edge, packages/common, and packages/ui make the client story easy to understand, while the Convex schema models users, projects, environments, flags, API keys, invites, password resets, and audit logs with useful indexes. The Edge README is much stronger than the root README, especially its default-value/error-handling guidance, and the React hook API is small enough to feel approachable.
The biggest adoption blocker is documentation. The root README.md is currently just a heading, so a new maintainer or user cannot quickly learn how to self-host, create a flag, configure an API key, run the dashboard, or choose between the JS, React, and Edge clients. I would move the strongest landing-page and Edge-package material into the root README, add a 5-minute quickstart, and document the architecture and environment variables. I also could not find test files, and the only workflow I saw is a manual package publishing workflow rather than CI for lint/build/test. For a feature flag system, tests around flag lookup, disabled/default behavior, API key validation, permissions, and realtime subscription cleanup would go a long way. Adding GitHub topics, a contribution guide, and a short roadmap would also help this new zero-star, zero-fork repo communicate maturity and invite outside feedback.
