Why FTF
Not another flag vendor. The layer that makes toggles work across your whole delivery.
LaunchDarkly and ConfigCat are good at the switch itself. FTF adds what a large organisation needs around it — releases, environments, governance and clean-up — and works with either of them, or on its own.
What FTF adds to LaunchDarkly and ConfigCat
They are good at the switch itself. FTF adds what a large organisation needs around it.
One switch, every application
A release goes live across policy, billing, claims and digital at once; each feature keeps its own kill switch. Releases
Promotion with a preview
Toggles move up from test to production with their settings — nothing re-entered by hand — and production's release switch is never changed by promotion. Promotion
The same screens on a laptop
Developers edit the toggles file in their own repo with FTF's screens, then promote and pull — like git push and pull. Local development
OpenFeature, any language
FTF speaks OpenFeature's remote-evaluation protocol: use its own SDKs, or one plain HTTP call. Nothing vendor-specific in your services. Open standards
Already on LaunchDarkly or ConfigCat? Keep it.
FTF works on its own, or in front of the LaunchDarkly or ConfigCat account you already have — both are included, and other providers can be added. Your applications only ever talk to FTF, so moving between them, or to FTF alone, changes nothing in your systems.
About 20 hours of toggle work with FTF. About 33–37 with the others.
One release, five applications, five environments: the person-time every role spends on toggles — BA, developers, QA, release manager — from defining them to removing them, and how many settings are re-entered by hand along the way.
| Per release, in hours | LaunchDarkly (Foundation) | ConfigCat | FTF |
|---|---|---|---|
| BADefine toggles in the stories | 2.3 | 2.3 | 2.3 |
| DevelopersCreate toggles with their attributes | 2.3 | 2.3 | 2.3 — in the repo, with FTF's screens |
| DevelopersLocal development | 2.3 | 2.3 | 0 — the repo file is the local setup |
| DevelopersMark each toggle implemented per application | — | — | 0.2 |
| DevelopersPull teammates' toggle changes, resolve clashes | — | — | 1.0 |
| DevelopersMerge the toggles file in git | — | — | 0.7 |
| QASwitch toggles to test each feature both ways | 1.9 | 1.9 | 1.9 |
| Release managerTrack release contents and readiness | 3.1 | 2.2 | 0.5 — release view, pending per application |
| Release managerRe-enter attribute rules in test, SIT, UAT, production | 3.4 | 3.4 | 0 — promotion carries it |
| Release managerSet each toggle per environment | 1.9 | 1.9 | 1.4 — promotions, previews reviewed |
| Release managerGroup into the release | — not on this plan | 2.3 | 0 — linked when created |
| Release managerCheck environments match | 1.9 | 1.9 | 0 — the preview shows it |
| Release managerGo-live: switching | 0.9 — 28 flags | 0.5 | 0.25 — one switch |
| Release managerGo-live: coordination | 8 — 2 h, 4 people | 3 — 1 h, 3 people | 1.5 — 30 min, 3 people |
| DevelopersClean-up: retire and remove toggles everywhere | 2.1 | 2.1 | 0.7 |
| DevelopersClean-up: remove toggle checks from the code | 7 | 7 | 7 |
| Total | ≈ 37 | ≈ 33 | ≈ 20 |
| Settings re-entered by hand between environments | ≈ 180, plus 28 go-live switches | ≈ 320 | none |
What slows a release down
The hours are spread over weeks. What delays a release is what goes wrong in them:
- Settings re-entered by hand are where environments start to differ. One mismatch found in UAT typically costs a re-test cycle — days, not minutes.
- Waiting for access. With a vendor, developers need someone with rights in the shared dev environment, or work in it and disturb each other. With FTF, developers, BAs and testers each work in their own place and promote when ready.
- Go-live as an event. Without release grouping, go-live is a scheduled window across applications. With FTF it's one switch, the day the business says go.
- Half-built features. In FTF a toggle stays off in an application until its code is marked implemented there; without that gate, a missed application is found in testing — or in production.
Assumptions and caveats
- A model, not a measurement — not yet checked against a real release. Minutes per action are estimates (5 to define or create a toggle, 3 to re-enter its rules, 1 to switch or check one, 15 to remove one from code); the ratios matter more than the hours.
- Scenario: two digital and three core insurance applications; dev, test, SIT, UAT and production plus developers' laptops; five developers; 20 features, about 28 toggles, 60% with attribute rules.
- Where FTF costs more: pulling teammates' toggle changes and merging the toggles file in git — the price of toggles living with the code.
- The same for everyone: defining toggles, testing both ways, and removing toggle checks from code (the largest single step, ≈ 7 h) are counted so the totals show the whole job. Building and testing the features themselves, and deployments, are not.
- LaunchDarkly Foundation has no environment copy (Enterprise) and no prerequisites (“selected plans”); Enterprise closes about half the gap, to ≈ 28 h. ConfigCat: prerequisites available, values per environment.
- Scripting the vendors' management APIs reduces re-entry — at the cost of building and maintaining the scripts.
- Vendor plans as published in October 2026; plans change.
Capabilities FTF introduces
The same screens on a laptop
Toggles live in a file in the developer's repo, edited with FTF's own screens. Promote to FTF and pull teammates' changes like git push and pull; a clash is shown, never silently overwritten. Same answers offline as in production.
One release, every application
A release toggle groups the features of one release across applications and switches them together. Each feature still has its own switch, so one bad part goes off without stopping the rest.
Off until the code is there
A new toggle stays off in an application until a developer marks it implemented there — so a switch can't turn on a feature that one application hasn't built yet.
Retired, then removed everywhere
A toggle is retired first and deleted in every environment only after that — tracked in FTF, whatever language the code is written in.
Promotion that respects production
Every vendor has environments. FTF moves toggles between them only upwards — test, UAT, production — shows every change first, flags what someone changed in the target since (who, when), and never flips a release's switch in production: going live stays a separate decision.
Your identity provider decides
Permissions come from the identity provider you already run, scoped to environments and applications. FTF keeps no users, roles or passwords of its own.
FTF next to LaunchDarkly and ConfigCat
Where they're equal, we say so. FTF can also sit in front of either one.
| LaunchDarkly | ConfigCat | FTF | |
|---|---|---|---|
| Switch features on and off, target customers, percentage rollouts | Yes | Yes | Yes — lists, number comparisons, sticky percentages, shared audiences |
| How an application connects | A language SDK in each service; server-side connections are counted per environment on paid plans | Language SDKs, or the self-hosted ConfigCat Proxy | One HTTP call from any language; small, dependency-free clients for JavaScript and Python |
| OFREP — OpenFeature's open standard for evaluating flags over HTTP, without a vendor SDK | No. No OFREP endpoint, in the service or in its Relay Proxy. OpenFeature is supported through providers built on its own SDKs, so an SDK is still needed | Yes, through ConfigCat Proxy (version 2 and later), which you host and run yourself. Also OpenFeature providers built on its SDKs | Yes, built in — nothing to host. Tested with OpenFeature's own Python, Node and browser providers |
| Switch a group of features as one release | Flag prerequisites, on selected plans | Prerequisite flags, set per environment | Release toggles across applications; each feature keeps its own switch |
| Move settings from test to production | Copying flag settings between environments is an Enterprise-plan feature | Values are set per environment | Promotion upwards only, with a preview; changes made in the target since are flagged; a release's switch in production is never changed by promotion |
| Local development | Local overrides for testing (SDK file data source, CLI dev server); flags are created in LaunchDarkly | Local flag overrides from a file | Toggles in a file in the developer's repo, edited with FTF's own screens, promoted and pulled like git push and pull, with clashes caught |
| Who may switch what | Managed in LaunchDarkly | Managed in ConfigCat | Your identity provider, per environment and application |
| Finding toggles that should go | Code References, stale-flag detection, archiving | Zombie-flag reports, Code References | Pending → implemented → retired → deleted everywhere, for code in any language |
| How it's priced | Per service connection and client-side monthly active users (pay as you go); Enterprise quoted | By config downloads; unlimited team members | Arranged with us |
| Changing vendor | Change the SDK (or OpenFeature provider) in every application | Change the SDK (or OpenFeature provider) in every application | Applications talk only to FTF; it works on its own or in front of LaunchDarkly or ConfigCat (both included), so moving between them changes nothing in your systems. Other providers on request |
LaunchDarkly and ConfigCat details are from their public documentation and pricing pages (for OFREP: LaunchDarkly's OpenFeature and Relay Proxy documentation, ConfigCat's Proxy documentation), October 2026; plans change, so check their current terms. LaunchDarkly and ConfigCat are trademarks of their owners.
Why it fits insurance platforms
FTF's model comes from how insurance core-system teams already release — releases and attributes — not from a web start-up's.
Insurance attributes
Brand, jurisdiction, line of business, claim amount, premium, a steady share of policies or accounts — whatever your application knows.
Policy, billing, claims and digital, together
A product change usually touches several systems. One release switch takes them live at the same moment, in every system.
Stop a feature, not the release
Switching a feature off stops new work from using it in seconds, with no redeploy. Records already created with it, such as a policy, a claim or an exposure, stay; the toggle decides how they are processed from then on.
Shorter system test
Test what's switched on. A feature that fails stays off and no longer holds the whole release in system test.
One codebase, several instances
Two installations of the same product — say, one per country — each have their own application name, so a toggle can be on in one and off in the other.
Audit and control
Every switch is recorded with who and when. Each customer's toggle names start with its own permanent prefix, so they never collide with anyone else's.
We're honest about the limits too: database changes, typelists, API contracts and batch schedules can't be toggled. They still move in small, safe steps — here's how.
Guidewire InsuranceSuite integration is available to design partners — talk to us.
See it with your own platforms
We'll walk through your release process and show where FTF fits.