FTF and Guidewire
Designed with Guidewire InsuranceSuite in mind.
FTF's model comes from how InsuranceSuite teams already release — releases and attributes — and from what core insurance systems need: long test cycles, several applications going live together, and no rolling back data once it has changed.
FTF GW client
How a Guidewire application uses FTF: one call in Gosu, toggles evaluated inside the application from its own copy, a purpose-built toggle and release console, and no code change between environments.
FTF GW client →Where FTF fits
A standalone Guidewire application, then integrated InsuranceSuite applications on the FTF provider, then any other OFREP-compliant application on the same FTF, on its own or in front of LaunchDarkly or ConfigCat.
Usage scenarios →Why it fits insurance platforms
Policy, billing, claims and digital, together
A product change usually touches several systems. One release switch takes them live at the same moment.
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.
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.
More in Why FTF: built for insurance. Some changes can't be toggled in any system — data model and typelist changes, API contracts, batch schedules: here's how they still move in small steps.