I’m Building a Feature Flag Platform. Here’s What I’ve Learned So Far
Building a real product with AI, previous engineering experience, and a growing appreciation for keeping things simple.
I’ve been working on a new feature flag platform.
What started as a personal project has turned into something much bigger: a real product that I’m planning to deploy, use for my own projects, use with freelance clients, and eventually open up to other solo builders, indie hackers, and small teams.
The idea came from a few different places.
I’ve spent time researching existing feature flag platforms, and while there are some great products out there, I kept running into the same problems: they were either too expensive for solo builders, too complicated for the way I wanted to work, or clearly designed around larger teams with more process, more budget, and more infrastructure than a solo developer or small startup usually has.
At the same time, I was recently involved in helping migrate feature flags to an internal implementation at work. That gave me a practical reason to think more deeply about how feature flags should work, what makes them useful, and where the complexity starts to appear.
So I started building.
At first, I thought of it as a way to experiment. Maybe just a simple implementation of boolean flags: true or false, on or off. But the more I worked on it, the more I realized there was room for something more useful.
Not necessarily more complicated.
More useful.
A feature flag platform that is actually built by and for solo builders, while still being capable enough for teams.
Feature flags are simple until they aren’t
On the surface, feature flags sound incredibly simple.
You create a flag. You turn it on or off. Your application behaves differently depending on the value.
That’s the basic idea.
But once you start using feature flags seriously, you quickly realize they are not just toggles. They become part of your release workflow. They affect how you deploy, how you test, how you recover from mistakes, how you roll out features, and how confidently you can make changes in production.
Over the years, I’ve used feature flags more and more as a software engineer. At first, they were just a convenient way to hide unfinished work. Then they became useful for safer deployments. Then for gradual rollouts. Then for kill switches. Then for managing different behavior across environments or users.
The more useful they became, the harder they became to manage.
That is the part that interested me.
Not just creating flags, but managing the lifecycle of them.
Because one of the problems with feature flags is that they can become messy. You add one for a release, then another for a customer-specific feature, then another for an experiment, then another as a temporary safety mechanism. Before long, you have flags everywhere, and nobody is completely sure which ones are still needed.
For solo developers and small teams, this can be even harder. You do not always have a platform team, a release manager, or a carefully maintained internal process. You need tools that help you work well without adding a lot of overhead.
That is one of the problems I want this platform to solve.
I want to teach and support a method of using feature flags properly: setting them up, using them intentionally, and cleaning them up when they are no longer needed. I also want the product itself to help with that through smart, timely helpers and notifications.
Feature flags should make your development process safer and faster.
They should not become another source of technical debt.
Why build another platform?
There are already feature flag tools.
That’s true.
But I think there is still room for a product that focuses heavily on solo builders, indie hackers, small startups, and developers building real things without enterprise-sized teams or enterprise-sized budgets.
The main reasons I started building this were pricing, simplicity, self-hosting, developer experience, speed, and workflow.
I wanted something that felt approachable for a single developer but did not artificially limit them. A platform that starts simple but can grow with the project. A platform where the first experience is not “invite your team and configure five layers of process,” but rather “create a flag, understand how to use it, and ship more safely.”
That does not mean teams are not part of the vision. They are. But I want the product to work well for the person who is building alone first.
A solo builder still needs good tools.
A solo builder still needs safe deployments.
A solo builder still needs clean environments, audit logs, SDKs, authentication, billing, metrics, and a sane developer experience.
They just need all of that without the product assuming they are already operating like a 100-person engineering organization.
What I’ve built so far
The product has progressed a lot in a relatively short amount of time.
At this point, it already has a public API, a console for managing flags, organizations, teams, projects, and environments, a marketing site, basic docs, SDKs, authentication, flag targeting, audit logs, Stripe billing, and basic metrics.
Authentication supports email codes, passkeys, Google OAuth, and GitHub OAuth.
The platform has concepts for organizations, projects, and environments, which is important because feature flags are not just global switches. A flag in development is not the same thing as a flag in production. A flag for one project should not accidentally affect another. Permissions and boundaries matter.
There are also background workers, an admin app, and several other moving pieces that make the product feel less like a toy and more like an actual platform.
That has been one of the most rewarding parts so far.
It is no longer just an idea or a prototype. It is almost ready for an MVP release and private beta. Soon, I’ll be able to start using it for my own personal projects and freelance clients, then slowly let in more users and scale up traffic over time.
That is exciting.
It is also where the complexity becomes real.
The real complexity is production workflow
The hardest part of building a feature flag platform is not creating a boolean flag.
That part is easy.
The hard part is building around a proper production workflow.
You have to think about how people will actually use the platform. You have to think about what happens when the product has users globally. You have to think about latency, data location, edge access, and how flags can be evaluated quickly and reliably from different parts of the world.
At some point, a Postgres database sitting in one region is not the entire answer. For many applications, especially ones geographically close to the database, that may be perfectly fine. But if you are building a feature flag platform, the question of global access becomes much more important.
Flags may need to be available globally. They may need to be evaluated from edge workers. They may need to support applications and users that are not physically close to the primary database.
That is where the project becomes more interesting.
A feature flag platform is simple at the API level, but it touches a lot of deeper engineering questions: scale, reliability, latency, permissions, auditability, and safety.
The toggle is simple.
The system around the toggle is where the work is.
Building with AI has been powerful, but not automatic
A major part of this project has been AI-assisted development.
I have used AI to generate a large amount of the code. But I do not think of that as “AI built the product for me.” That would be the wrong way to describe it.
AI has accelerated the work significantly, but I have still had to review, refactor, restructure, test, and make judgment calls constantly.
The project is built as a monorepo, which has helped with easy updates, migrations, shared code, and keeping the platform organized as it grows. There are unit tests, integration tests, and end-to-end tests to verify that things actually work. I have also been using proper PRD documents so that features are specced before implementation instead of just blindly generating code and hoping it all fits together.
That is one of the biggest lessons so far.
AI can generate code quickly.
But speed is not the same thing as correctness.
It can be risky if you do not review the code and test it properly. It can create something that looks right but has poor structure, misses edge cases, introduces security issues, or does not fit the long-term direction of the product.
The value comes from combining AI with engineering judgment.
You need to know when to accept something, when to reject it, when to refactor it, and when to step back and change direction completely.
For me, being able to program has helped significantly. Being able to read code has helped even more. It is not just about knowing whether the syntax is valid. It is about understanding what is happening at both a low level and a high level.
What is this code doing?
How does it fit into the rest of the system?
Is this abstraction useful or unnecessary?
Is this secure?
Will this be maintainable later?
Does this make the next feature easier or harder?
That kind of context matters a lot.
AI is powerful, but it needs direction. Previous experience with developer experience, architecture, packages, security, and production systems has helped me guide it instead of being guided by it.
Security matters more than people think
Feature flags can affect production behavior.
That makes security and trust extremely important.
A bad permission check, a leaked API key, or a poorly designed environment boundary could cause real problems. Flags can control access to features, change user experiences, enable incomplete work, affect billing-related behavior, or turn important functionality on and off.
So the platform needs to be built carefully from the beginning.
That means thinking about authentication, authorization, organization boundaries, environment separation, audit logs, API keys, SDK keys, admin permissions, secret management, rate limits, data isolation, and protecting production flags from accidental changes.
A lot of this comes down to using industry best practices and standards, but it also comes down to experience. You have to know what to look for. You have to know where the dangerous parts of the system are. You have to think about what should happen when something goes wrong.
Security is not something I want to bolt on later.
It has to be part of the shape of the product.
Local development setup is key
One of the strongest lessons from this project has been that a proper local development setup is not optional once a product has a lot of moving pieces.
In the early stages, you can sometimes get away with running one app locally and manually wiring things together. But once you have an API, console, marketing site, docs, background workers, admin app, database, billing integration, authentication, and SDKs, that stops being enough.
A good local setup saves money, reduces risk, and makes development much faster.
It means you can test changes without touching production databases, staging environments, or CI pipelines. It means you can bring up a brand new environment wherever you need it. It means you can experiment, break things, reset things, and keep moving.
Docker Compose has been excellent for this.
The platform’s local development environment is set up so the different apps and services can run together. The Stripe CLI is also part of the billing workflow, which makes testing payment-related behavior locally much easier.
One detail I really like is being able to use local domains such as:
api.flags.localhost
console.flags.localhost
That makes the local environment feel much closer to the real production setup. It also helps with browser behavior around cookies, sessions, and domain boundaries. Instead of everything being awkwardly spread across random localhost ports, each app can behave more like a real subdomain in a real deployed environment.
That has made local development much smoother.
It also makes AI-assisted development safer. When the whole system can be run locally, tested locally, and verified locally, you are not just trusting generated code. You are proving whether it works.
The hardest part has been keeping it simple
The product has grown to over 100,000 lines of code.
That creates a different kind of challenge.
At that size, the hardest part is not always writing more code. Sometimes the hardest part is deciding what not to build.
Keeping things simple has been difficult. Not overbuilding has been difficult. Knowing what to do next has been difficult. Testing everything properly has been difficult.
When you are building a platform, especially one with many separate apps and services, it is easy to justify almost anything.
Maybe this needs a new abstraction.
Maybe this needs a more flexible workflow.
Maybe this should support every possible future use case.
Maybe this should be enterprise-ready from day one.
But that is dangerous.
One of the lessons I keep coming back to is to start simple while still making choices that can scale later.
For example, keeping each app specific to what it should do. The public API should be public-facing. The console should be self-contained. Internal concerns should not leak everywhere. The system should be understandable.
That kind of separation matters.
Not because every product needs a complicated architecture, but because once a product grows, unclear boundaries become expensive.
What I’d tell other developers building with AI
If another developer wanted to build a serious product with AI assistance, my advice would be simple: start small, but choose foundations that can scale.
Do not blindly generate a massive product and assume it is good because it runs.
Review the code. Read it. Test it. Refactor it. Understand it.
Use AI to move faster, but do not outsource your judgment.
The more context you have, the better AI becomes as a tool. If you understand the product, the architecture, the security model, and the developer experience you want, AI can help you get there much faster.
But if you do not understand what you are building, AI can also help you create a mess very quickly.
That is the balance I have been learning through this project.
AI has helped me build faster.
Experience has helped me build better.
Where things are now
Right now, the platform is close to an MVP release and private beta.
The goal is to start using it on my own projects and with freelance clients, then gradually let in more users as the product matures.
I’m proud of how much progress I’ve made in a matter of weeks. What started as an experiment around simple boolean feature flags has grown into a real platform with authentication, billing, environments, targeting, audit logs, metrics, SDKs, background workers, and multiple apps working together.
There is still a lot to do.
But that is also the point of this series.
I want to share the process as I build: the decisions, mistakes, tradeoffs, technical lessons, AI development workflow, local setup, security considerations, and product thinking behind it.
This first post is the start of that.
I’m building a feature flag platform for solo builders, indie hackers, small startups, and teams that want something simple, practical, and flexible.
I’m building it because feature flags are useful, but managing them well is harder than it looks.
And I’m building it in public because the lessons along the way are worth sharing.
Subscribe to follow the journey.