Your company needs a feature flag and experimentation platform. A vendor charges a substantial annual fee; a team estimates six weeks to build one. Decide.

Apply the differentiation test first

Is this a source of competitive advantage? Feature flagging is context, not core: customers do not choose you for it, and being better at it than the market changes nothing.

That is the primary filter, and it points at buy before any cost comparison.

Then correct the six-week estimate

The estimate is for the first version. What it omits, and what should be added explicitly:

Ongoing maintenance, which for a platform of this kind typically exceeds the initial build several times over across its life.

The features discovered later: percentage rollouts, targeting rules, an audit trail, SDKs for every language in the estate, low-latency evaluation with local caching, a usable interface for non-engineers, statistical analysis for experiments, and the ability to survive its own outage without breaking every service that depends on it.

Operational ownership — this becomes a production dependency of every service, so it needs an SLO, an on-call rotation and a capacity plan.

Opportunity cost — six weeks plus ongoing maintenance not spent on the product.

Key-person risk, when the person who built it moves on.

Realistically this is a multiple of the estimate, and the comparison is against engineer cost, not against zero.

And correct the vendor cost

Integration effort, routinely underestimated. Licence growth as seats or evaluations scale, which is where these contracts become expensive. Constraints the vendor's model imposes on your design. And exit cost — how hard it would be to leave, which is the honest way to reason about lock-in rather than avoiding it on principle.

The decision

Buy, unless one of a small set of specific conditions holds: a regulatory constraint that prevents sending evaluation context to a third party; scale at which the licence exceeds the fully-loaded build and run cost; or a requirement no vendor meets.

Note the middle option, which is frequently right: buy the platform and build the thin differentiated layer — the integration with your identity model, your deployment pipeline, your metrics.

Manage the lock-in rather than avoiding it

Wrap the vendor SDK in a small internal interface, so evaluation calls in application code do not name the vendor. That is a day of work and it makes the exit a contained change rather than an estate-wide one.

Do not build a full abstraction over hypothetical alternatives — that is building the thing you decided not to build.

What a strong answer adds

Naming the availability consequence. A flag platform becomes a synchronous dependency of every service unless designed otherwise: local evaluation with cached rules and a fail-static default if the platform is unreachable. Whether you buy or build, that design point matters more than the procurement decision.