Top 7 Optimizely alternatives for SaaS companies

A SaaS feature flag sits at the intersection of customer identity, product packaging, release safety, and recurring revenue. That makes a generic flag checklist inadequate.

Optimizely is a capable baseline for web and feature experimentation. Feature Experimentation can target application attributes, deliver SDK-based variations, and support progressive releases, while Web Experimentation covers browser-based optimization. A SaaS team should verify account-level bucketing explicitly because the commercial customer, not the individual browser, is often the correct randomization unit.

SaaS teams still have valid reasons to compare alternatives. A growing B2B company may want experiment results based on subscription revenue in its warehouse. A bootstrapped product may need pricing that does not rise unpredictably with client-side users or service topology. A regulated vendor may need self-hosting. Another team may want analytics, replay, and surveys in the same system as flags. Those needs lead to different winners.

This guide compares 7 Optimizely alternatives for SaaS companies: GrowthBook, Statsig, PostHog, Unleash, Flagsmith, ConfigCat, and DevCycle. GrowthBook ranks first for its combination of feature delivery, warehouse-native experimentation, account-level business metrics, open source, and traffic-independent core pricing. Statsig is the deepest integrated alternative for teams that want group analytics and advanced experimentation. PostHog is a practical all-in-one suite. Unleash and Flagsmith provide strong open-source deployment control. ConfigCat is the focused managed option, while DevCycle is the standards-oriented choice for engineering teams.

SaaS experiments cross the website-product boundary

A SaaS buyer may use Optimizely for public pricing pages, signup, onboarding, in-product features, account permissions, and renewal journeys. Those are not one technical surface. Marketing-page changes may use a visual editor and visitor cookie; product changes may require server assignment, workspace identity, billing events, and a release flag.

Map each recent experiment to visitor, user, account, or subscription identity. Then record whether the outcome lives in browser events, application events, or the warehouse. An alternative that excels at landing pages may fail account-level product tests, while an SDK-first platform may require engineering for every marketing variation. The shortlist should match where the decisions with the greatest business impact actually occur.

Optimizely alternatives for SaaS companies at a glance

These rankings weigh tenant consistency, experiment analysis at the right unit, subscription and revenue metrics, environment governance, runtime behavior, deployment choice, migration effort, and cost at SaaS scale. A vendor is not a better fit merely because its entry plan is cheaper.

Model the SaaS control plane before choosing a vendor

Separate entitlements from release flags

Feature flags and SaaS entitlements can use similar conditions but have different failure consequences. A release flag answers, “Should this implementation be exposed now?” An entitlement answers, “Has this account purchased or been granted access?” The first is delivery control. The second is authorization and contract enforcement.

Do not make a browser-side flag the only barrier around a paid or sensitive capability. Keep the authoritative plan, add-on, trial, and exception state in a server-side billing or authorization service. Pass verified attributes such as plan, accountId, region, or hasReportingAddon into flag evaluation, but enforce protected operations on the server. The OWASP Application Security Verification Standard is a useful independent reference for keeping access-control requirements explicit.

This separation also makes migrations safer. You can replace the release-control provider without rewriting the source of truth for customer contracts. If a flag service is unavailable, the application can fail according to a known release default while authorization continues to enforce the paid boundary.

Choose the correct randomization and analysis units

B2B experiments often fail because they assign by user and analyze by account. Ten people at one customer can receive both variations, contaminating account-level retention or expansion metrics. If the product experience spreads through collaboration, mixed assignments can also make the treatment impossible to interpret.

Choose an account or organization identifier as the randomization unit when all members should share an experience. Join outcomes at that same unit or at a finer-grained unit that maps to exactly one account. If the number of customers is small or sizes vary sharply, power and balance become harder. Research on cluster-randomized experiments explains why the number and correlation of groups—not merely the number of users—affect precision.

User-level assignment can still be right for isolated interactions, such as individual notification preferences or a personal editor shortcut. Write down when users in one tenant may see different variants, how accounts with multiple workspaces behave, and what happens when a user changes employers or belongs to several organizations.

Price the architecture, not an imaginary average user

SaaS workloads stress meters differently. A browser product generates client-side monthly active users. A backend with many services can create service connections or configuration requests. A serverless architecture can initialize frequently. An experiment-heavy team emits exposures and events. A multi-product company needs more projects and environments.

Build a 12-month model with client MAU, server instances or connections, config fetches, evaluation requests, events, seats, projects, environments, data retention, and support. Include a 5-times-growth scenario and a noisy-neighbor incident. Practitioner threads about Optimizely alternatives and cost are useful for discovering questions, but only an architecture-specific model can predict your bill.

Treat flag cleanup as recurring SaaS maintenance

Temporary release flags become permanent complexity unless teams track owners, expected lifetimes, code references, last evaluations, rollout state, and removal work. Long-lived entitlement flags are different: they represent stable packaging and should be named, documented, and audited as such.

The distinction is supported by practitioner research on feature-toggle practices, which identifies management and cleanup as part of the discipline. During evaluation, create one release flag, one experiment flag, one operational kill switch, and one entitlement-adjacent flag. Verify that the platform can distinguish their lifecycles instead of placing every toggle in one undifferentiated list.

1. GrowthBook: Best overall for SaaS companies

Best for

GrowthBook is the best Optimizely alternative for SaaS companies that want release control and experimentation to use the same customer and business data already governed in a warehouse. It fits B2B products measuring account activation, seat expansion, churn, support load, gross margin, or annual recurring revenue, as well as product-led SaaS products running high volumes of user-level tests.

Key strengths

GrowthBook Feature Flags supports custom attributes, targeting rules, percentage rollouts, prerequisites, multiple environments, remote configuration, and local evaluation through lightweight SDKs. A SaaS application can pass account identifiers, plan, region, cohort, and verified entitlement attributes into the evaluation context. For an account-wide rollout, the team can use a stable organization identifier as the bucketing attribute and keep every member together.

The larger advantage is measurement. GrowthBook Experimentation queries existing warehouse data and lets teams define reusable SQL metrics. A SaaS team can analyze trial activation, retained accounts, paid conversion, expansion revenue, usage-based cost, or support tickets without rebuilding them as vendor-specific events. The same governed definition can power an experiment, a dashboard, and product analytics without a reconciliation layer.

GrowthBook supports Bayesian and frequentist analysis, CUPED, sequential testing, sample ratio mismatch checks, dimensions, guardrails, holdouts, and mutual exclusion. That depth matters when SaaS experiments affect correlated outcomes: an onboarding change may improve activation while increasing cancellations or support load. The open-source GrowthBook repository exposes the application and statistics, and both cloud and self-hosted deployment remain options.

Watchouts

GrowthBook cannot correct an ambiguous tenant model. Your SDK context, exposure table, metrics, and warehouse joins must agree about userId, accountId, workspace membership, and time-varying plan state. Decide whether a user with access to 2 accounts receives one assignment or an assignment per account, and include the relevant account in the experiment key.

Warehouse-native analysis also requires data ownership. A young SaaS company without reliable product events or subscription tables may need to start with the managed warehouse or do more instrumentation work than it would in a plug-in analytics suite. Self-hosting shifts operational responsibility to your team.

Pricing and implementation notes

The current GrowthBook pricing page lists a free Cloud Starter plan for up to 3 users and 1 project with unlimited feature flags, experiments, and traffic. Pro is $40 per seat per month with up to 50 users and 3 projects, plus advanced statistics, product analytics, permissions, and safer rollout features. Enterprise is custom. The open-source self-hosted plan is free, while commercial self-hosted controls are custom.

Seat-based core pricing is attractive for SaaS products whose customer traffic grows faster than the internal team. Model CDN and managed-warehouse allowances separately, but do not assume every end user or experiment exposure creates the main platform charge. For the pilot, use one account-level flag and an outcome sourced from the subscription warehouse, then inspect the SQL and assignment data with engineering, product, and finance stakeholders.

2. Statsig: Best integrated platform for B2B experiments

Best for

Statsig is best for SaaS teams that want feature gates, dynamic configuration, experiments, group analytics, product analytics, and session replay in one system. Its custom unit support is particularly relevant to B2B companies that need to assign and analyze by company, account, workspace, device, or another domain entity.

Key strengths

Statsig lets experiments use custom unit IDs such as companyID or accountID. Everyone at the same customer can receive the same variation, and the platform can analyze company- or account-level metrics. Its pricing comparison also lists group analytics explicitly for B2B products, alongside behavioral cohorts, funnels, retention, feature gates, experiments, and warehouse-native deployment.

The experimentation system is broad: Bayesian and frequentist methods, CUPED, sequential tests, holdouts, stratified sampling, interaction detection, switchback tests, non-inferiority tests, scorecards, and reusable metrics. Product teams can connect a partial rollout to metric lifts, while engineering manages gates and dynamic configs. Public Statsig SDK repositories provide implementation visibility.

Statsig Cloud can minimize data-platform setup, while Enterprise offers warehouse-native deployment for Snowflake, Databricks, BigQuery, Redshift, Athena, and Fabric. That gives a SaaS company a choice between an integrated event pipeline and analysis closer to governed warehouse data.

Watchouts

The commercial and roadmap context is changing. OpenAI announced the Statsig acquisition in 2025, and Amplitude announced in May 2026 that it took on the Statsig brand and customers and would maintain the cloud and warehouse platforms while developing an integrated roadmap. Confirm the contracting entity, support path, SDK commitments, and future relationship between Statsig and Amplitude before a long migration.

Event pricing also needs careful modeling. An exposure can be billable when it powers experiment or metric-lift workflows, and SaaS applications can generate large event volumes from active users. Group-level experiments may reduce the number of randomization units without reducing raw behavior events.

Pricing and implementation notes

The current Statsig pricing page lists a free Developer tier with 2 million events per month, unlimited flag and config checks, 1-year analytics retention, and unlimited seats. Pro is $150 per month for one project with 5 million included events, then $0.05 per 1,000 additional events. Enterprise supports custom event- or experiment-based contracts and warehouse-native deployment.

Pilot the hardest B2B case, not a user-level button test. Assign by account ID, include accounts of different sizes, measure one account-level outcome and one user-level guardrail, and verify how Statsig handles users in multiple accounts. Ask the vendor to show exactly which exposures, events, dimensions, and computed metrics count toward the plan.

Compare SaaS operating models

See how GrowthBook and Optimizely differ across warehouse data, feature delivery, experimentation, deployment, and pricing.

Compare GrowthBook and Optimizely

3. PostHog: Best all-in-one option for SaaS startups

Best for

PostHog is best for small and midsize SaaS teams that want to consolidate product analytics, web analytics, session replay, surveys, feature flags, experiments, error tracking, and warehouse tools. It is especially useful before a company can staff separate analytics, experimentation, research, and feature-management platforms.

Key strengths

PostHog can associate events with groups such as companies or organizations. A SaaS team can analyze activation, retention, and behavior by account while still inspecting individual users. Feature flags and experiments use the same persons, properties, cohorts, and events, allowing a PM to move from a funnel to a session replay, cohort, rollout, and test without several data handoffs.

The PostHog experiments workflow sits on feature flags and supports A/B or multivariate variants, goal and secondary metrics, and statistical analysis. Surveys and replay can add qualitative context to a result. The open-source PostHog repository makes much of the platform visible and lets technical buyers inspect how its systems evolve.

PostHog also offers unlimited team members and per-product billing limits. That makes it feasible for product, engineering, customer success, support, and design to share the same evidence during a startup pilot instead of buying access role by role.

Watchouts

Group analytics is a priced add-on to identified event analysis, and the complete SaaS workflow can touch several meters: analytics events, identified events, group analytics, feature-flag requests, recordings, surveys, and data pipelines. Cost is transparent, but it is not one number. Build the model from actual traffic samples.

PostHog is event-native. If finance-approved ARR, subscription status, refunds, costs, or customer-health scores live in the warehouse, confirm how they enter the experiment analysis and how often they refresh. An integrated interface does not automatically make the event taxonomy a source of truth.

Pricing and implementation notes

The current PostHog pricing page includes monthly free allowances of 1 million analytics events, 1 million feature-flag requests, and 5,000 session recordings. Experiments are billed with feature flags. The free plan includes 1 project, 1-year retention, and unlimited team members; pay-as-you-go unlocks 6 projects, longer retention, and email support. Group analytics starts at an additional per-event rate.

During the pilot, instrument a company group and associate its users and subscription properties. Run one account-cohort rollout, inspect both user and group analytics, and calculate the combined monthly cost. Verify identity merging for an anonymous evaluator who signs up, joins a workspace, switches accounts, and upgrades during the experiment.

4. Unleash: Best for open-source feature operations

Best for

Unleash is best for SaaS engineering teams that want a mature open-source feature-management control plane, custom targeting logic, and a path from self-hosted software to supported cloud or enterprise deployment. It fits organizations that prioritize delivery operations more than built-in experiment analysis.

Key strengths

The Unleash context model supports standard user and session fields plus arbitrary custom properties. A SaaS team can define tenantId, plan, region, isTrial, or accountRisk fields and use them in strategy constraints. Custom stickiness can hash on an account field so a gradual rollout or variant remains consistent for everyone in the tenant.

Activation strategies, reusable segments, variants, projects, environments, and a playground provide practical release control. Unleash also tracks a flag lifecycle from Define through Develop, Production, Cleanup, and Archived, helping teams distinguish active rollout work from stale code. The Unleash repository and public SDKs support technical due diligence and self-hosted adoption.

Commercial Unleash adds change requests, four-eyes approvals, roles, SSO, audit history, additional environments, data residency, and supported hosting. Those controls can suit a SaaS vendor that must prove who changed a production customer rollout and when.

Watchouts

Unleash is primarily a feature-management system. Flag variants and metrics do not amount to the warehouse-native statistical analysis available in experimentation specialists. A team that needs causal results for activation, churn, or revenue should pair assignments and exposures with a governed analysis layer.

Important SaaS capabilities cross the open-source and commercial boundary. The open-source edition supports one environment, while cloud and enterprise packages provide unlimited environments and more governance. Custom stickiness is documented as an Enterprise capability. Confirm the edition required for account-level rollouts before designing around it.

Pricing and implementation notes

The current Unleash upgrade page lists cloud hosting at $75 per seat per month and self-hosted Enterprise at $75 per seat per month billed annually with a 5-seat minimum. Cloud includes unlimited MAU, unlimited projects and environments, and 53 million API requests per month, with $5 per additional million. Custom enterprise contracts are available.

For a proof of concept, run the open-source edition and a trial of the commercial package if you need multiple environments or custom stickiness. Use a tenant ID context field, compare decisions across 2 SDK languages, test the playground, export configuration, and send evaluation data to your chosen analytics system. Price the external experiment-analysis work alongside the Unleash subscription.

5. Flagsmith: Best for deployment flexibility

Best for

Flagsmith is best for SaaS companies that want one feature-management model across managed cloud, dedicated private cloud, and self-hosting. It is a strong fit for vendors with data-residency, customer-isolation, or regulated deployment requirements that may evolve as they move upmarket.

Key strengths

Flagsmith uses identities, traits, and segments for targeting. A SaaS app can identify a user and pass traits such as tenant, plan, region, beta status, or account tier, then use segments to serve Boolean or multivariate flags. The open-source Flagsmith repository includes the control plane, and its SDKs support web, mobile, and server applications.

Deployment choice is the differentiator. Teams can use the global managed service, choose a single-tenant private cloud in a selected provider and region, or deploy on their own infrastructure. Server-side local evaluation keeps decisions in process after configuration is loaded, which can reduce runtime dependence on an external request path.

The commercial tiers add scheduled flags, A/B and multivariate testing integration, roles, permissions, change requests, audit logs, SAML, and support. Unlimited flags, environments, identities, and segments make the object model friendly to a multi-product SaaS portfolio, subject to fair-use and request allowances.

Watchouts

Flagsmith can assign variants and integrate with analytics, but it is not a full statistical experimentation platform. Define where exposures, outcomes, power calculations, guardrails, and final decisions will live. Do not label a 50/50 multivariate flag as an A/B test until that measurement layer exists.

Managed-cloud pricing is request-based and team collaboration changes by tier. Server-rendered pages or frequent identity refreshes may use more API calls than a single-page application that caches flags for a session. Enterprise governance and non-public deployment are custom-priced.

Pricing and implementation notes

The current Flagsmith pricing page lists a free cloud plan with 50,000 requests per month, 1 team member, and unlimited flags, environments, identities, and segments. Start-Up is $45 per month for 1 million requests and 3 members. Scale-Up is $300 monthly for 5 million-plus requests and 5 included members, with governance features. Enterprise is custom for cloud, private-cloud, or self-hosted deployments.

Sample your actual SDK behavior before forecasting. Flagsmith counts calls that fetch flags for an application or identity; a React session and server-rendered page can create different patterns. In the pilot, target 3 real tenant shapes, test local evaluation and stale configuration, exercise a change request, and export the objects needed for a future migration.

6. ConfigCat: Best focused managed flag service

Best for

ConfigCat is best for SaaS teams that want a straightforward managed flag and remote-configuration service without adopting a broad analytics suite. It works well for smaller B2B products that need customer-specific targeting, stable percentage rollouts, generous configuration delivery, and published plan limits.

Key strengths

ConfigCat targeting uses a user object, custom attributes, segments, prerequisite flags, and ordered rules. Percentage options are sticky and consistent across SDKs. A custom percentage attribute can use a company or organization value, allowing a SaaS team to keep users at the same customer in the same rollout group.

ConfigCat evaluates rules through its SDKs and requires a caller-supplied default value, making fallback behavior explicit. It supports Boolean, string, integer, and double settings, so teams can use the service for remote configuration as well as release flags. Its SDK repositories allow engineers to verify platform coverage and update activity.

The service also publishes detailed limits for products, environments, flags, segments, percentage options, configuration downloads, and traffic. That transparency makes it easier for a SaaS team to test projected scale before procurement.

Watchouts

ConfigCat provides targeting and stable variant distribution, but experiment analysis belongs in another platform. A team must log assignments and connect them to account outcomes with the correct unit and statistical method. That separation can be perfectly reasonable for a flag-first use case; it is extra architecture for an experimentation-first program.

Migration is not a pure object copy. Providers differ around fractional rollout percentages, segment rules, variation values, missing attributes, and percentage keys. A translation that succeeds can still change edge-case evaluation semantics, so shadow decisions before cutover.

Pricing and implementation notes

The current ConfigCat pricing page and plan-limit documentation list a forever-free plan with 10 flags, 2 products, 2 environments per product, 2 segments per product, 5 million configuration downloads, and 20 GB of monthly traffic. Higher tiers increase product, environment, flag, segment, delivery, collaboration, and governance limits; confirm the current displayed price for the selected billing period.

Use the migration converter on representative complex flags, not just Boolean defaults. Test tenant-based percentage allocation, plan and region rules, prerequisite flags, confidential comparisons, missing attributes, and offline defaults in every SDK language you operate. Connect the evaluation details to your existing analytics stack if experiments are in scope.

7. DevCycle: Best for OpenFeature-oriented SaaS engineering

Best for

DevCycle is best for engineering-led SaaS teams that want OpenFeature across client and server SDKs, strong debugging and schema tools, reusable audiences, flag lifecycle support, and experimentation attached to the feature workflow. It is well suited to organizations that want provider abstraction in application code without giving up a managed control plane.

Key strengths

DevCycle supports unlimited seats, flags, projects, and environments across its plans. Targeting can use custom properties such as accountType, pricingPlan, isSubscriber, or isTrialUser. Reusable audiences can group beta customers, tenant IDs, or account tiers, while schemas constrain variables and custom properties.

Its feature experimentation supports A/B and multivariate tests, custom metrics, gradual and scheduled rollouts, and measurement for frontend, backend, algorithm, architecture, and database changes. The documentation explicitly discusses randomizing with custom properties for company-level tests and the increased balance risk when group counts are small.

DevCycle is OpenFeature-native and publishes providers and SDK integrations through GitHub. It also provides CLI, API, editor, Terraform, code-reference, and debugging tools. Those surfaces can reduce migration coupling and help engineers understand a tenant's actual flag decision during support incidents.

Watchouts

OpenFeature standardizes evaluation APIs, not the provider's management model, experiments, audit history, or pricing. Switching providers still requires mapping flag types, rules, segments, environments, configuration delivery, and exposure semantics. Treat the standard as one portability layer rather than a one-click exit plan; the CNCF OpenFeature project documents that broader ecosystem boundary.

DevCycle's commercial step is substantial for a smaller SaaS company. The Business tier adds permissions, audit logs, stale-flag detection, and stored custom properties, but it begins at a higher base price and meters client MAU, cloud config requests, server config requests, and events. DevCycle is also now part of Dynatrace, so confirm current contracting and roadmap expectations.

Pricing and implementation notes

The current DevCycle pricing page lists a free plan with unlimited seats and flags, 1,000 client-side MAU, 10,000 cloud config requests, 100,000 server config requests, and 5,000 events per month. Business is shown at $500 per month billed annually, with 100,000 client MAU and larger request and event allowances; the detailed base price is $625 monthly before the annual discount. Enterprise is custom.

Build a usage model for each SDK mode. Local-bucketing server SDKs consume configuration fetches differently from cloud bucketing, and experiments add custom events. In the pilot, evaluate the same tenant context through the native SDK and OpenFeature provider, test schema violations and offline defaults, run an account-level experiment, and export the data needed to reproduce the result.

Which alternative fits your SaaS stage?

Early-stage SaaS with a small team

PostHog can consolidate the most product tools with little procurement overhead, while ConfigCat is the cleaner choice when the need is narrowly managed flags. GrowthBook's free cloud and open-source paths are stronger when the team already knows that rigorous experimentation and warehouse data will matter. Do not choose only by the free allowance; model the first paid boundary you are likely to cross.

Scaling B2B SaaS with a data warehouse

GrowthBook and Statsig lead here. GrowthBook is preferable when the warehouse remains the source of truth, SQL transparency matters, and traffic-independent core pricing is valuable. Statsig is compelling when the organization wants a tightly integrated event, analytics, flag, and experiment suite with custom unit IDs. The Statsig-Amplitude transition should be part of commercial diligence.

Regulated or deployment-sensitive SaaS

GrowthBook, Unleash, and Flagsmith offer self-hosted operating models. Flagsmith adds a managed single-tenant private-cloud option. Compare editions carefully: open-source availability does not imply that SSO, audit history, approvals, multiple environments, or commercial support are included. Add database operations, upgrades, disaster recovery, and on-call staffing to self-hosted cost.

Engineering-platform-led SaaS

Unleash is strongest when mature flag operations and lifecycle controls are the priority. DevCycle is strongest when OpenFeature, developer tooling, schemas, debugging, and experimentation inside the feature workflow matter. ConfigCat is attractive when a team wants a smaller managed dependency with explicit targeting and delivery limits.

A SaaS-specific proof of concept

Give every finalist the same tenant model and production-like traffic. A useful proof of concept includes these checks:

1. Represent a user, an account, a workspace, plan, region, trial state, and verified add-ons without exposing unnecessary personal or commercial data.
2. Serve one flag consistently to every user at an account, including a user who belongs to 2 accounts and switches between them.
3. Run an account-randomized experiment with enough companies and balanced account sizes. Measure activation or retention by account and latency by request.
4. Change a customer's plan during the test. Verify when targeting changes, whether the assignment remains valid, and how analysis treats the transition.
5. Simulate provider timeout, stale configuration, malformed context, missing account ID, and a rollback during peak traffic.
6. Exercise development, staging, canary, and production environments. Test approval, audit, API, CI/CD, and break-glass workflows with real roles.
7. Shadow-evaluate 20 representative Optimizely flags and compare every decision. Include segments, prerequisites, multiple variants, and edge-case attributes.
8. Inventory flag configuration, historical changes, code references, experiment records, and raw exposure data. Confirm which artifacts can be exported.
9. Calculate cost at current volume, expected year-end volume, and 5-times growth across every meter and required add-on.
10. Assign owners for identity contracts, metrics, SDK upgrades, incident response, entitlements, and stale-flag removal.

Use independent sources to challenge the demo. G2's Optimizely Web Experimentation alternatives can reveal categories buyers compare, while community discussions about small-team feature flags surface real setup and pricing anxieties. The OpenFeature specification helps test API portability, and Martin Fowler's feature toggle guidance remains a useful vocabulary for separating release, experiment, operational, and permissioning toggles. Validate every current capability and price on the vendor's official pages.

GrowthBook is the strongest overall choice for a SaaS company because it connects tenant-aware feature delivery with the governed business data needed to judge product changes. Warehouse-native analysis makes account retention, expansion revenue, support cost, and product usage first-class metrics. Open source and self-hosting preserve deployment choice, while seat-based core pricing remains predictable as customer traffic grows. Start a free GrowthBook pilot with one tenant-wide rollout, or book a SaaS experimentation demo to review the data model and migration plan.

Pilot with real SaaS metrics

Connect account and subscription data, ship a tenant-aware rollout, and measure its impact with one platform.

Start a GrowthBook Pilot