What does feature flag and A/B testing platform cost actually depend on?
The open-source tiers of GrowthBook, Unleash and Flagsmith carry no license fee for self-hosting, so the real cost of a self-hosted platform is staff time, hosting, integration work and any Enterprise features you need. Whether you build in-house, hire an implementation partner or pay for a SaaS plan, those four lines decide the total. The SaaS vendors publish subscription prices, but a self-hosted deployment has no equivalent line item, so the comparison only works if you price the people and infrastructure yourself.
The answer depends on three things: the edition you need, where your data must sit, and how much you are migrating. The free self-hosted editions are limited in different ways. Unleash Open Source is capped at 1 project and 2 environments, and GrowthBook's self-hosted Open Source plan omits SSO, SCIM, approval workflows and holdouts that its self-hosted Enterprise tier adds. Flagsmith places SAML single sign-on and governance features such as roles, change requests and audit logs at its Scale-Up plan, which is a paid cloud tier. Ask each vendor which features your controls require and whether they are available in the edition you would run, since that choice sets the license line for the next several years. Data location changes hosting and integration effort, because evaluation and experiment analysis may need to run inside your network or against your own warehouse. Migration scope changes implementation cost, since importers for LaunchDarkly and Statsig differ in coverage and vendor documentation warns that advanced setups may need manual rework.
DeployOpen plans, implements and supports self-hosted platforms inside your own infrastructure, and it does not publish a price list. A quote follows from a written, fixed scope that names the edition, hosting model, data sources, migration inventory and support terms. Before requesting one, confirm your Enterprise feature list, your database and Kubernetes standards, and the number of flags and experiments you expect to migrate. Those inputs are the main drivers of any quote, and they are the questions a partner should ask you first.
Which cost lines sit in-house, with a partner, and in SaaS
This table compares where each cost line for a self-hosted feature flag and A/B testing platform lands under in-house build, implementation partner, or SaaS subscription. Read each row for who is paid, whether the cost is one-time or recurring, and which vendor price is supplied. The main takeaway is that subscription prices cover only part of total cost, and self-hosting moves the recurring work to your own staff or a retainer.
| Cost line | In-house | Partner | SaaS |
|---|---|---|---|
| Licence or subscription | Open-source tiers are free to use: GrowthBook Open Source, Unleash Open Source and Flagsmith self-hosted. Enterprise editions need a negotiated licence. | Partner fees are separate from software licences. The partner does not replace the vendor's edition terms, so confirm which edition you are licensing. | Recurring. GrowthBook Cloud Pro at $40 per seat per month (GrowthBook pricing page). Unleash Pay-As-You-Go at $75 per seat per month with a 5-seat minimum for self-hosted (Unleash pricing page). Flagsmith Start-Up at $40 per month billed yearly and Scale-Up at $250 per month billed yearly (Flagsmith pricing page). |
| Hosting and database | Recurring cloud or data center costs for the application, PostgreSQL or MongoDB, and caching. Your team sizes and patches these. | Recurring infrastructure, usually billed to you directly. The partner designs and deploys the environment but does not usually absorb the bill. Confirm this in the quote. | Included in the subscription. Data location depends on the vendor's regions, so confirm where evaluation and storage happen. |
| Edition features | Enterprise features such as SSO, SCIM, approval workflows and change requests need a paid licence even when hosting is in-house. Enterprise features are not free to build yourself. | Partner can configure and test licensed features. The features themselves still require the vendor's paid edition. | Governance features are tied to higher tiers. Flagsmith places SAML SSO and roles, change requests and audit logs from Scale-Up upward (Flagsmith pricing page). Confirm tier fit for each control you need. |
| Migration from an existing tool | One-time. Export flags as JSON, recreate segments and rules, and run both systems in parallel. Staff time is the main cost. | One-time fixed-scope work. Scope depends on the number of flags, targeting rules and SDK changes, which must be agreed in writing. | One-time. Vendor importers exist for LaunchDarkly and Statsig, but imports need manual checks and SDK switches (GrowthBook import documentation). |
| Identity and data warehouse integration | Recurring engineering for identity provider connections and warehouse access. GrowthBook runs only SELECT queries and sends back aggregates, which helps scope the work. | One-time build of connectors and access controls, plus support during changes. Access tokens and service accounts must be managed in your environment. | Vendor-managed connectors for common sources. Confirm which data sources and identity features your plan supports, because some are gated to higher tiers. |
| Staff time for operations | Recurring. Upgrades, backups, on-call and flag cleanup fall to your platform team. Effort rises with the number of environments and SDKs. | Recurring only if you buy a retainer. Retainers cover upgrades and support as agreed, so confirm response scope and hours. | Largely removed from your team for the platform. Your team still owns flag lifecycle, targeting logic and experiment design. |
| Support and upgrades | Community support for open-source tiers. Your team tracks releases and security fixes. Unleash Edge OSS reaches end of life on December 31, 2026 (Unleash Edge documentation). | Retainer support, upgrades and testing can be fixed-scope or ongoing. Ask for the upgrade path for each vendor release. | Vendor support tied to your plan. Confirm response terms and what happens to flags during a vendor outage. |
| Change management evidence | Recurring. Your team builds approval records, audit trails and access reviews, which may need extra tooling if the edition lacks change requests. | One-time design of evidence procedures, plus periodic review. The partner prepares evidence but does not issue audit opinions. | Audit logs and approvals are available on higher tiers. Confirm export format and retention before relying on them for assessments. |
How build, partner and SaaS differ by platform edition
When your own engineers deploy GrowthBook, Unleash or Flagsmith, your team pays for every line item directly: the time spent on installation, SDK integration, database operations, upgrades and on-call coverage. The software license for the open-source core is typically no charge, so the budget mostly consists of staff time and the infrastructure you run it on. Most of the cost is one-time in the setup phase and recurs in operations, because each new release needs testing and each flag needs an owner.
- Staff time: Platform, security and product engineers absorb installation, configuration and the first integration, usually with no separate line item in the budget.
- Infrastructure: Compute, a managed or self-run database such as PostgreSQL or MongoDB, and backups recur every month.
- Edition limits: Unleash Open Source is limited to 1 project and 2 environments, so a second product line may force an Enterprise purchase or a second instance.
- Governance features: GrowthBook's Enterprise directories cover approval workflows and advanced permissions, and Flagsmith starts role-based access, change requests and audit logs at Scale-Up. Building these yourself is possible but is custom work you must maintain.
- Upgrades: Each release, such as GrowthBook v5.1.0 or Flagsmith v2.286.0, needs regression testing before it reaches production.
Ask your team to list the hours for each of these items and who owns them after go-live, because that list is what a partner quote would be compared against.
With an implementation partner, you pay a fixed-scope fee for the planning, deployment, integration, hardening and documentation work, and your team keeps ownership of the platform afterward. The partner fee is usually one-time for the project, while hosting, licenses you choose to buy and any ongoing support retainer recur. Scope agreed in writing before work starts is what makes the one-time portion predictable.
- Fixed scope: The partner's fee covers the deliverables named in the statement of work, such as a Helm-based deployment, SDK integration and a migration plan.
- Migration work: Importers exist for LaunchDarkly and Statsig in some platforms, but the GrowthBook LaunchDarkly importer warns that advanced setups may need manual work, and the application must still change SDKs.
- Recurring support: A retainer for upgrades and monitoring is optional and priced separately from the project.
- Your internal time: You still need owners to make decisions, review flag definitions and approve changes.
- Edition choice: A partner can advise whether the open-source core is enough or whether the Enterprise tier, such as Unleash Enterprise or the Flagsmith Scale-Up plan, is needed.
Bring a list of your flag count, environments, identity provider and migration sources to the scoping call, and ask the partner to show which costs are fixed and which change if scope grows.
A SaaS subscription moves hosting, upgrades and most operations to the vendor, and you pay a recurring fee based on seats, requests or projects. Vendor pricing is published for some plans: GrowthBook Cloud Pro lists $40 per seat per month for up to 30 users, Unleash Pay-As-You-Go lists $75 per seat per month with a 5-seat minimum for self-hosted, and Flagsmith Start-Up lists $40 per month billed yearly. Costs rise as seats, requests or flags grow, and the premium tiers are often custom priced.
- Recurring fees: Subscription cost grows with seats or request volume, so it recurs for the life of the contract.
- Request overages: Flagsmith lists $50 per million additional API calls per month on Free, Start-Up and Scale-Up plans.
- Data location: Targeting attributes leave your infrastructure, which may conflict with residency or sector rules.
- Internal time: Integration and SDK work remain yours, even though operations move to the vendor.
- Exit cost: Moving off a SaaS platform later requires exporting definitions, which Unleash and Flagsmith support in different forms.
Compare the published seat price with your projected seat count and request volume over the contract term, and confirm in writing which features sit in each plan.
Which drivers move each cost line up or down
Six variables set most of the difference between a SaaS subscription and a self-hosted setup. Each one moves infrastructure, licensing, implementation or internal staff time in a predictable direction, so you can ask a vendor or partner to price them explicitly.
Seat count and approval workflows
Per-seat SaaS pricing scales with the number of people who edit flags or view experiments, so headcount is the first line to model. Approval workflows, change requests and role-based access are often the features that move a team off the free tier. On GrowthBook, the free self-hosted Open Source plan does not include approval workflows, and on Unleash, change requests sit in Enterprise. Check which governance features you need before you count seats, because they can change the edition, not just the price.
Projects and environments
Project and environment counts are a common reason teams outgrow free editions. Unleash Open Source is limited to 1 project and 2 environments, so separate staging, production and regional setups push you toward a paid plan. Each additional environment adds configuration, review and testing effort even when licensing does not change. Ask vendors how their limits are counted and whether they apply per instance or per account.
Warehouse connection for experiment analysis
Warehouse-native analysis moves cost into data engineering work: credentials, read-only query access, metric definitions in SQL and query compute on your own warehouse. GrowthBook runs only SELECT queries against your data source and transmits aggregated statistics, which shifts cost toward warehouse compute and modeling time. A SaaS tool that stores event data in its own system may reduce that work but adds data egress and retention questions. Confirm which warehouse you use and who owns metric definitions before estimating this line.
Identity integration with SSO and SCIM
Single sign-on and SCIM provisioning are typically Enterprise features on self-hosted editions, so they are a licensing decision as much as an identity one. Flagsmith places SAML single sign-on at its Scale-Up plan, and Unleash includes SSO and SCIM in Enterprise. Without SCIM, someone must create and remove accounts by hand, which adds recurring administration time. Ask whether the edition covers your identity provider and whether the integration is in scope of the implementation quote.
Migration from LaunchDarkly or Statsig
Migration is usually a one-time cost that scales with the complexity of existing flags, segments, prerequisites and experiments. GrowthBook's LaunchDarkly importer warns that advanced setups may include cases it cannot handle, and the application still has to switch from the LaunchDarkly SDK to a GrowthBook SDK. Flagsmith's importer overwrites existing flags in the target project, so careful review adds time. Count flags, segments, SDK call sites and parallel-run periods before you request a quote.
High availability on Kubernetes with an external database
Running production on Kubernetes with a managed external database adds recurring infrastructure cost and one-time platform engineering effort. Flagsmith's Helm chart creates its own PostgreSQL in the cluster by default, while its documentation recommends an externally managed database for production. Managed databases, replicas, backups and monitoring each carry their own fee and operating time. Confirm which database service, replica count and backup retention your architecture requires, and whether the partner or your team owns patching and failover.
Why migration from an existing vendor is the biggest variable
For most teams that already run a feature flag vendor, migration rather than the license fee decides the real cost of a self-hosted platform. The importers are a starting point, not a finished move. GrowthBook's LaunchDarkly importer fetches projects, environments and flags into a preview, but its own documentation warns that advanced setups may include scenarios it cannot handle, and the application still has to replace the LaunchDarkly SDK with a GrowthBook SDK after the import. The Statsig importer covers gates, dynamic configs and experiments, while metric sources and metrics remain in beta and are limited to warehouse-native Statsig metrics. Confirm which of your flags, experiments and metrics fall outside those limits before you estimate effort.
Flagsmith's LaunchDarkly importer is more direct but carries a different risk. It overwrites existing environments and flags in the target project, so an import into a project that already holds configuration can replace it. It also brings archived and deprecated flags across as archived, and its documentation says the result should be checked by hand. Unleash moves configuration as JSON, but segments and custom strategies are exported only as references, so they must exist in the target before the import runs. Recreating them, and mapping LaunchDarkly rules to activation strategies, is manual work that a migration plan has to name and assign.
The Unleash migration guide recommends running both systems in parallel behind an abstraction layer before cutting over. Parallel running is where staff time and infrastructure cost accumulate: two sets of flags to keep in sync, two SDK integrations, duplicated monitoring and a period in which engineers must know which system is authoritative. Ask any implementation partner to price the parallel period explicitly, including who maintains the abstraction layer and how long both systems stay live. Those hours, not the subscription line, are often what separates a build from a partner-led move.
How to build your own cost estimate step by step
This sequence turns a vague budget question into a line-by-line estimate that separates subscription fees, infrastructure, staff time and partner work, so you can compare build, partner and SaaS options on the same basis.
List the edition features you actually need
Start with the feature list, not the price list. Write down which capabilities your teams need on day one, such as single sign-on, SCIM provisioning, role-based access, approval workflows, audit logs, holdouts or safe rollouts. Vendor pricing pages show that several of these sit only in paid tiers. For GrowthBook, the free self-hosted Open Source plan does not include SSO, SCIM, approvals or holdouts. Unleash Open Source is limited to 1 project and 2 environments. Flagsmith places SAML and governance features at its Scale-Up plan. Done when every must-have feature is tied to a named tier from the vendor's current comparison, and the features that only the open-source edition provides are marked as such.
Count seats, projects and environments
Next, size the units that vendors bill or limit on. Count the people who will create or approve flags and experiments, the projects you will run (one per product or team is a common split, but confirm how your chosen vendor counts them), and the environments you need, such as development, staging and production. Count evaluation volume separately, because some vendors cap API requests or flags per instance while the self-hosted open-source editions may not. Done when you have a seat count, a project count, an environment count and a monthly request estimate, each with a short note on how it was derived.
Choose the hosting model and database
Decide where the platform runs and which database backs it. Self-hosted options run on your cloud accounts or data centers, so the cost lines include compute, storage, backups, load balancing and the database service. GrowthBook stores metadata in MongoDB or a compatible database and suggests a managed service for production. Unleash runs against PostgreSQL 15 or later. Flagsmith's Helm chart creates its own PostgreSQL by default, while its documentation recommends an externally managed database in production. Ask your platform team to price the environments in your own cloud or data center, and confirm the high-availability and backup design. Done when each environment has a named database service and a rough infrastructure line that your finance and platform teams have reviewed.
Scope identity and warehouse integration
Identity and data connections are often the largest unplanned work. Scope the integration with your identity provider for single sign-on and provisioning, and confirm which of these need an edition that includes them. If you plan to analyze experiments in your own warehouse, list the data sources involved, such as BigQuery, Snowflake, Postgres or Databricks, and who owns the metric definitions. GrowthBook runs only SELECT queries and sends back aggregated statistics, but someone still has to build and maintain the metric SQL. Done when each integration has an owner, an agreed interface, and a written estimate of the engineering days from your own team or a partner.
Scope the migration from your current tool
If you already run a SaaS flag or experimentation tool, price the migration separately. Export your flag, segment and experiment definitions, then check which parts the importers handle. GrowthBook's LaunchDarkly importer warns that advanced setups may include cases it cannot handle, and the application still has to switch SDKs. Unleash's guide recommends running both systems in parallel behind an abstraction layer before cutting over. Count the flags to convert, the SDK changes in each application, and the parallel-run period you need. Done when you have an inventory of flags and experiments, a list of flags that need manual rebuilding, and a plan for how each application will switch.
Assign internal staff hours by role
Estimate the internal time for each role: platform or DevOps engineers for deployment, upgrades and monitoring; security staff for access, logging and review; data engineers for warehouse work; product and engineering leads for flag governance; and compliance staff for evidence. Record hours per role for the build phase and for the recurring run phase separately. Keep the staff cost as a separate line from vendor and infrastructure fees, because it is often the largest recurring cost in a self-hosted model and it is easy to leave out. Done when each role has a monthly and a one-time hour estimate, a loaded hourly rate from finance, and a named owner who has accepted the figures.
Add partner scope and an optional support retainer
Decide which work you will hand to an implementation partner and which you will keep in-house. Typical partner scope includes platform planning, installation, SDK integration, migration, hardening, backup configuration and documentation. If you want ongoing help after go-live, price a support or upgrade retainer separately, since most DeployOpen engagements are fixed-scope and ongoing support is available as a retainer. Request a written scope with deliverables, exclusions and acceptance criteria from each candidate, and ask how upgrades and version changes are handled. Done when you have at least one written scope and quote for the partner work, and a clear list of what remains with your own team.
Separate one-time from recurring costs and confirm prices
Sort every line into one-time costs (planning, installation, migration, integration, hardening and documentation) and recurring costs (subscriptions, infrastructure, database services, staff time for operations, support retainers and renewals). Then confirm current pricing directly with each vendor and partner, because published pages change and quotes depend on your scope. Build the model for each option, build, partner or SaaS, on the same time horizon, and mark which assumptions drive the result. Done when the model shows one-time and recurring totals for each option, every number has a source or a stated assumption, and the written quotes and vendor confirmations are attached.
When an implementation partner costs less than building alone
A fixed-scope partner engagement costs less than building alone when the cost of doing the work in-house is higher than the quoted scope, which usually happens for one of four reasons: no platform engineers on staff who can own a self-hosted flag service, a migration with a hard cutover date, compliance evidence that must exist before an assessment, or Enterprise features that need configuration on day one. The comparison is not fixed. It depends on your own loaded staff rates, how many weeks of engineering time the build would take, and how much of that time would otherwise go to product work. Ask your team to price the build in hours before you compare it with any quote.
The strongest case for a partner is a migration. Both GrowthBook and Unleash publish migration paths from LaunchDarkly, and Flagsmith has a built-in LaunchDarkly importer, but each importer documents cases it does not handle and leaves manual checks. GrowthBook's own documentation says the application still has to switch from the LaunchDarkly SDK to a GrowthBook SDK after the import. Unleash recommends running both systems in parallel behind an abstraction layer before cutover. Those steps need engineers who know the target platform and the source platform, and a partner that has scoped them up front converts an open-ended effort into a deliverable with a known finish. Illustratively, a team with no spare engineers and a fixed contract renewal date would usually pay less for a scoped migration than for a rushed internal one that slips.
A build is usually cheaper when you already run Kubernetes, PostgreSQL or MongoDB operations well, have engineers who can own upgrades, and need only the open-source edition. Be honest about the limits of that edition: Unleash Open Source is limited to 1 project and 2 environments, and Flagsmith keeps governance features such as roles, change requests and audit logs for its Scale-Up plan and above. If you need those controls, the cost comparison shifts toward Enterprise licensing, which is quoted, so get written pricing from each vendor before you decide. Confirm your own staff rates, the hours a build would take, and whether a partner quote includes hardening, backup and upgrade support after go-live.
Questions buyers ask about feature flag platform cost
What does a self-hosted open-source feature flag platform cost?
The software license is free on the open-source tiers, so the cost sits in infrastructure, database operations, implementation and staff time. The Open Source plans from GrowthBook, Unleash and Flagsmith are free to self-host, but each has limits that push teams toward paid editions: GrowthBook's free self-hosted plan allows 1 project, Unleash Open Source allows 1 project and 2 environments, and Flagsmith's open-source version has no API request limits but gates SAML single sign-on and governance features behind Enterprise. Check the current figures on each GrowthBook pricing page, Unleash pricing page and Flagsmith pricing page. Ask each vendor which features your governance requirements depend on, because those decide whether the free tier is enough.
How much internal effort does self-hosting a flag platform need?
Effort depends on how many environments you run, how you handle identity, and whether you already operate Kubernetes and managed databases. A typical self-hosted setup needs someone to run the application server, its database (GrowthBook uses MongoDB or a compatible database, Unleash uses PostgreSQL 15 or later, and Flagsmith recommends an externally managed database in production), upgrades, backups and SDK integration in product code. The recurring effort is usually upgrades and on-call coverage, not the first install. Before you estimate, inventory the teams that will use the platform, the SDK languages in use and the number of environments. Ask any partner to break its effort down by installation, integration, upgrade and support so you can see which line your team would carry.
How long does a feature flag rollout take and what drives it?
The timeline is driven by the number of applications that must adopt the SDK, the migration of existing flags, and the approvals your change process requires. A greenfield install with a few services moves faster than a migration from a commercial platform with hundreds of flags. Migration tooling helps but has limits: GrowthBook's LaunchDarkly importer warns that advanced setups may include scenarios it cannot handle and still requires an SDK switch, and Flagsmith's importer overwrites existing flags in the target project, so imported flags need manual checks. Unleash recommends running both systems in parallel behind an abstraction layer before cutting over. Ask for a written scope that names the services, flags and environments in the first phase, since fixed scope and fixed dates depend on that list.
Can our engineering team run this without an implementation partner?
Yes, many teams do, provided they have engineers who can operate containers, a managed database and an identity provider. The open-source Docker images and Helm charts are documented, and the quick starts are short. The harder parts are production hardening, SDK rollout across services, flag lifecycle governance, and the evidence trail that auditors sample. Those tasks compete with product work for the same people. A partner makes sense when the platform must meet an audit or change-management standard in a short window, when edition gaps push you toward a paid tier, or when internal staff lack the time. DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted platforms in your own infrastructure, under fixed-scope agreements in writing.
What does the work need from our team?
The work needs decisions and access from your side more than it needs code. You will need to name an accountable owner for the platform, provide hosting and database capacity, connect identity and single sign-on, and supply data access if experiments will be analyzed in your warehouse. Engineering must agree on SDK integration patterns and on who may change flags in production. Plan for reviewers who can sign off on flag changes and for a named contact who can approve the written scope. Ask any partner to list each dependency on your side with an owner and a date, because delays on access and approvals are the most common reasons a fixed scope slips.
What recurring costs remain after go-live?
After go-live, recurring costs fall into four groups: infrastructure, database operations, software upgrades and support. Infrastructure and managed database fees scale with traffic and environments, and SDK request volume can raise edge or proxy costs. Upgrades need regular testing because release cadences move quickly; GrowthBook, Unleash and Flagsmith all publish frequent releases, and Unleash Edge's open-source version reaches end of life on December 31, 2026. Enterprise licenses, where needed, add per-seat or per-request fees: Unleash lists Pay-As-You-Go at $75 per seat per month with a 5-seat minimum for self-hosted, and Flagsmith prices additional API calls at $50 per million per month on its lower tiers. Ask for a quote that separates one-time work from annual support and retainer fees, so the recurring line is visible before you commit.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted feature flag and experimentation platforms inside your own infrastructure. We start from a written scope that sets which platform, edition, data sources and integrations are in and out, so the cost comparison in this guide turns into a quote you can check line by line.
How we scope
- Confirm which platform and edition fit the flag and test volume, the number of seats and the Enterprise features you need.
- Map the data sources used for experiment analysis and state which systems receive only aggregated results.
- Agree in writing on deliverables, timelines, exclusions and what a retainer for ongoing support would cover.
How we build
- Deploy the chosen platform into your cloud account, data center or air-gapped network with your database and identity setup.
- Connect SDKs, identity and access controls, and any import of flags from an existing vendor, then check imported flags by hand.
- Test flag evaluation, rollback paths and experiment analysis against your own environments before anything goes live.
How we hand over
- Document the architecture, licence obligations, upgrade steps and the ownership split between your team and ours.
- Provide the cost model and staff-time estimates behind the scope so finance and engineering can review the same numbers.
- Deliver runbooks, configuration records and change evidence that your internal and external reviewers can sample.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, priced from the agreed scope rather than a price list.
- Track upstream release notes and licence changes so your team knows when an upgrade or edition decision is due.
- Keep the self-hosted platform, its backups and its access controls under your control after handover.
