Topic

Build vs buy: feature flag systems

Neither choice is universally correct. A modest config table and a library wrapper can carry a small product for years; a growing portfolio of environments, auditors, and real-time experiments tends to push teams toward specialised services — or toward a deliberate internal platform team.

When building in-house can suffice

A small surface area, few environments, and a tolerance for manual change processes sometimes mean a database column or config file plus a thin client is enough. The cost is ongoing: someone must own schema migrations, access control, SDK updates, and on-call when evaluation breaks at scale.

When a productised service earns its fee

Operational load

Hosted offerings typically bundle delivery pipelines for rule updates, auditing UI, role-based access, and multi-region concerns. If your organisation already runs a platform team with spare capacity, you may still choose to self-host — but account for their roadmap time.

Compliance and audit expectations

Industries with strict change control often value immutable history, approvals, and exportable evidence. Verify whether a vendor's model matches your auditor's questions before you standardise on it.

Portability and standards

Abstractions such as OpenFeature exist so application code depends less on a single vendor's API shape. Buying or building, consider how hard it would be to swap the provider behind your evaluation calls.

Total cost, not sticker price

Include engineering time for maintenance, incident response, training product and support staff, and the drag of stale flags left in code. A cheaper monthly invoice can hide expensive internal hours — and vice versa.