Create a Feature Flag Project

A project is one application you want to control with flags. Everything else (flags, environments, SDK keys, rules) lives inside it.

Create it

The project screen appears right after you set up your organization. You can also add projects later from the project switcher in the top navigation.

Choose the Feature Flags type

The create-project dialog asks for a type first: Web Experimentation or Feature Flags. Pick Feature Flags. This is the one choice on the page you cannot change afterwards, because the two types have different screens: a flags project has an Environments page and no snippet, a web project has a snippet and no environments.

Name it

Something you will recognise at a glance: "Checkout Service", "Mobile API", "Web App". A flags project does not ask for a website URL, because your code is what evaluates the flags, not a page we load.

Create the project

A vs B creates the project along with two environments, Production and Development, each with its own SDK key. There is no environment setup step to do.

Keep the install screen open

The last onboarding screen shows the SDK key for your production environment and the install command. It waits there, live, until your SDK checks in for the first time. You can skip it: the same panel comes back as a card on your dashboard until the install is proven.

The New Project dialog with the Feature Flags project type card selected, next to Web Experimentation, followed by a Name field

Select the Feature Flags card. You cannot change this after creating the project.
Name the project, then select Create Project.

The Connect your SDK onboarding screen, showing the production environment's SDK key and a status message. This demo project's SDK has already checked in, so the status reads 'Your SDK is connected' rather than the initial waiting state.

Copy the SDK key shown here for your production environment.
Leave this open, or skip it. Either way, it waits for your app's first check-in and confirms it live.

What you get

Thing	What it is
Production environment	Key `production`, SDK key starting `sdk_production_`. The real one.
Development environment	Key `development`, SDK key starting `sdk_development_`. For local and staging work.
Flags	None yet. You'll create the first one after installing the SDK.

Each environment holds its own copy of every flag's configuration, so a flag can be on in Development and off in Production at the same time. That is the point of environments: you test the change where nobody is watching, then publish it where everyone is.

An SDK key is readable by anyone using your app, exactly like a web analytics id, so it is safe to ship in client-side code. What is not safe is shipping the wrong one: an app running on your Production key reads Production values, so a developer testing with it changes what your customers see. Use the Development key while you build.

Where to find your keys later

Open your project and go to Environments. Every environment shows its SDK key with a copy button, its connection status, and a View SDK setup instructions button. That button opens install code with your real key already in it, so there is no placeholder to replace.

The Environments page, showing the Production and Development environment cards, each with its SDK key, a connection status indicator, and a View SDK setup instructions button

Each card shows that environment's SDK key with a copy button.
The dot and label show whether an SDK has checked in recently.
View SDK setup instructions opens ready-to-paste code with your real key.

What happens next

Time to put the SDK in your application. Continue to Install the SDK.