Your checkout component renders perfectly. The layout looks right, the tax rate loads, the payment methods appear. Everything passes your visual check — and then you deploy, and users get the experimental beta layout when they shouldn't.

The bug? A feature flag with the value "false" — a string, not a boolean. In JavaScript,
a non-empty string is truthy. So the flag that was supposed to disable the experimental UI was quietly enabling it for every single user. TypeScript had no idea, because it had no idea your feature flags existed at all.

This is the quiet danger of untyped feature flags. They fail silently, they're hard to reproduce in tests, and they tend to surface at the worst possible moment. Here's how to close that gap with generated TypeScript types — and a few additional best practices that make your flags easier to maintain as your codebase grows.

Why TypeScript Doesn't Save You (By Default)

Most React developers working with feature flags write something like this:

const { isExperimental, taxRate, headline, paymentMethods } =

This looks reasonable. But TypeScript has no way of knowing:

• Whether isExperimental is a real flag name in GrowthBook
• Whether it should be a boolean, a string, or a number
• Whether your fallback value type matches the default defined in your dashboard

Without type definitions, the SDK treats everything as any. You can pass a string where
a boolean belongs, misspell a flag name, or reference a flag that's been deleted — and your code compiles without complaint. The result is a whole category of bugs that are genuinely hard to catch: everything looks fine at the TypeScript layer, but the runtime behavior is wrong.

The Fix: Generated Type Definitions for Your Feature Flags

The solution is to give the GrowthBook React SDK a TypeScript interface that describes all your flags — their names and their value types — so the compiler can enforce correctness for you.

GrowthBook provides a CLI tool to generate these types. But if you're using Cursor or another AI-assisted editor with MCP support, there's an even faster path: you can generate the types directly through GrowthBook's MCP server without leaving your editor.

Either way, the result is a file called app-features.ts that contains a complete TypeScript interface for every flag in your GrowthBook account:

export interface AppFeatures {
  checkout_experimental_layout: boolean;
  headline: string;
  shipping_tax: number;
  payment_methods: string[];
}

Three More Feature-Flag Best Practices Worth Adding

Type safety solves the hardest category of feature flag bugs, but there are a few additional practices that will save you headaches as your flag usage grows.

Handle Loading States Explicitly

When your app initializes, GrowthBook fetches flag values from the server. During this brief window, the SDK relies on local fallback values. If not handled explicitly, this can result in a "flash of unstyled content" (FOUC) where users see the wrong UI state for a split second.