Building your own feature flag platform might be a mistake

Feature flags play a critical role in software development. And they should: They’re great for enabling developers to manage features in a way that’s controlled and targeted.

A lot of companies we’ve worked with started off with a home-grown solution. At some point they each found feature management made a lot more sense for what they needed. 

Here’s why.

The typical journey of building a home-grown feature flag platform

Early setup

When embarking on a home-grown feature flag solution, developers often start by creating: 

  • a flag configuration API for controlling feature states, 
  • a flag configuration UI for managing flags, 
  • a database for storing flags, and 
  • an SDK for their preferred programming language.


An early setup home-grown feature flag platform might look like this.


With this setup, they can control the percentage of users who have the feature enabled, then gradually increase it over time. 

However, as the project progresses, managing these flags becomes more complex, revealing hidden challenges.

Complexities emerge

As our developer delves deeper into feature flagging, they eventually realize that a basic on/off switch is inadequate. 

More and more the developer needs to support more flexible and customizable experiences with feature variations. They need to enable things like A/B testing to compare the performance of different feature implementations. 

Plus, there’s a good chance the developer’s company is a polyglot and uses multiple programming languages. This means they need to write SDK clients for all those languages and maintain APIs with extensive documentation.

In this context, building and constructing a feature flag platform becomes daunting for our developer.

Scaling challenges

Still, the developer’s team keeps charging ahead with feature flags, as they do offer amazing benefits. And then scalability concerns kicks in.

Our developer finds themselves managing reusable flag enabling criteria. They need to maintain groups like early customers, internal users, or other context-specific conditions. 

Additionally, the developer needs to organize flags into projects based on their company’s team structures. They have to maintain an event history to track changes in those projects, and handle permissions. 

As their company grows, our developer and their team needs to protect themselves from unintended changes, such as when a sales team alters flags for a demonstration.

New challenges begin to emerge like health reporting and stale feature flag management.

A well-designed feature flag management platform should encourage the use of mostly short-lived feature flags. This nudges developers towards removing obsolete flags to maintain a clean and efficient system. 

Feature flag maintenance can take a lot of time when part of a home-grown solution. Even worse is the technical debt that can build up with layers of unused, obsolete flags.

One more layer of complexity: Larger companies typically become more prone to compliance regulations. Our developer may need to implement a four-eyes approval process similar to GitHub pull requests. 

Making the jump to feature management with strategic distillation

Domain-driven design (DDD) offers a strategic distillation technique that can give our developer a way out of their conundrum. 

The idea is to categorize  different parts of a domain to avoid the pitfalls of building everything in-house.

DDD divides a domain into three areas.


When deciding on whether to outsource feature management, you should consider the domain feature management belongs in.


Your core subdomain is where you make money. Things you do in-house to support your business are in your supporting subdomain.

Your generic subdomain is everything else you get off the shelf so you don’t have to build it yourself.

This technique is great for forcing our developer to ask: Does my home-grown feature flag platform provide a competitive advantage? 

In other words, will our developer’s customers notice a difference if their team doesn’t  build a feature platform themselves? Is our developer spending time on complex problems that don’t set them apart from others?

With strategic distillation, companies can determine whether building a home-grown feature flag platform in a supporting subdomain justifies the costs. 

If not, developers can turn to ready-made solutions like Unleash to minimize expenses and allow team members to focus on more critical tasks.


Building a home-grown feature flag platform can be more complex than it initially seems. 

By incorporating strategic distillation techniques from Domain-Driven Design, developers can better assess whether a home-grown solution is worth the effort or if a ready-made solution is more appropriate. 

Opting for a feature flag management solution like Unleash can save time, money, and effort. More importantly, it frees your developers to focus on their core tasks and ensure the successful implementation and management of feature flags.


Find out for yourself what open-source feature management can do


Share this article