Feature flag and A/B testing platform requirements checklist

The checklist itself is mostly internal time: product, engineering, security and data staff agreeing on which requirements are must-haves. The effort grows with the number of teams that will create flags, the number of environments, whether experiments must read from your own warehouse, and how many approval and audit rules apply. Platform licensing is a separate line. The free self-hosted editions of GrowthBook, Unleash and Flagsmith have different limits: the GrowthBook Open Source plan allows 1 project, Unleash Open Source allows 1 project and 2 environments, and Flagsmith's self-hosted open-source version has no API request limits. Governance features such as SSO, SCIM, approvals and change requests sit in paid editions, so list them as requirements early. Ask any implementation partner for a fixed-scope quote built from this list, which names deliverables and the work each one includes.

The length depends on scope, and no supplied figure gives a standard duration, so confirm the estimate in writing with any partner. A narrow proof of concept covers one application, one SDK, a single environment and a few flags, and is largely a deployment and integration exercise. A broader one adds an identity provider, a database that meets your backup rules, a data source for experiment analysis and a migration test from an existing tool. Migrations take longer because each tool exports differently. GrowthBook's LaunchDarkly importer, for example, warns that advanced setups may include scenarios it cannot handle, and the application still has to switch SDKs after import. Ask for the proof of concept scope, the success criteria and the exit conditions before work starts.

Four groups of inputs decide whether the evaluation moves quickly. The first is identity: which identity provider will authenticate administrators, and whether SAML or OIDC is available to the platform's paid tier. The second is data access: a read-only connection to the warehouse or database that will hold experiment results, with SELECT rights, since GrowthBook runs only SELECT queries and transmits aggregated statistics. The third is environments: the hosting account, Kubernetes cluster or Docker host, the database service and the network rules. The fourth is owners: a named person for each flag category, an approver for production changes and someone responsible for retiring stale flags. Missing owners cause more delay than missing technology, so settle them before the first install.

Often yes for a small proof of concept. A capable platform team can start a Docker Compose or Helm-based instance, connect an SDK and test targeting rules without outside help. The risk appears when the evaluation touches production-grade hosting, identity integration, migration from another vendor, or evidence for an audit. Flagsmith's Helm chart creates its own PostgreSQL server by default, while its documentation recommends an externally managed database in production. Unleash's getting started guide requires PostgreSQL 15 or later, and its Edge caching layer's open-source version reaches end of life on December 31, 2026. Your team should decide which of these tasks it can own over the long term, since an evaluation that cannot be operated after go-live gives little useful information.

Ask for a written list of what the edition you plan to run includes, not what the marketing page implies. Confirm the following for each platform:

• Whether SSO and SCIM provisioning are in the edition you will buy, and whether they are open source or require a license
• Whether role-based access, custom roles and change requests or approval workflows are included
• Project and environment limits, and how API request limits and seat counts are billed
• Which license covers the code you will host, since GrowthBook, Unleash and Flagsmith each separate enterprise code from the core
• Support terms after go-live and the versions that will receive fixes

These answers change the total cost more than the list price does.

The requirements list grows in three areas. Hosting: the platform, database, cache and any Edge or proxy component must run inside your boundary, with no outbound calls you have not approved. Images and updates: you need a way to mirror container images, Helm charts and release packages into the network and to test them before promotion. Evidence: approvals, audit logs and configuration exports must be retained in a form your auditors can sample. Export and import of flag configurations is the main way to move changes between isolated environments, and segments must exist in the target before import. Confirm with each vendor which features work without internet access, and which paid features you need for approval trails. A partner can help define the boundary, but the regulator or auditor determines what evidence is sufficient.

Start with licensing and hosting constraints, then compare features. Licensing decides what you may run and modify. GrowthBook states that code outside its enterprise directories is MIT licensed while those directories fall under its Enterprise License. Flagsmith says most of its code is BSD 3-Clause, with Enterprise features closed source. Unleash moved its source code to AGPLv3 starting with v8.0.0, while its official Docker images stay under Apache 2.0. If you modify Unleash and offer it as a public or commercial service, the AGPLv3 terms apply. Have legal counsel review the license text for your use case. After that, compare how each platform handles your required data location, identity model and experiment analysis, since those requirements eliminate options faster than feature lists do.

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a flag platform, that can include scoping the requirements, deploying a proof of concept in your environment, connecting identity and the experiment data source, and preparing the configuration and records an audit may request. DeployOpen does not issue audit reports or certifications, and it does not set the vendor's licensing terms. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. Ask for the exclusions in writing as well as the included work.