How to Add Feature Flags to an AI-Built App

How to add feature flags to an AI-built app comes down to one idea: store the on/off decision somewhere your app checks at request time, instead of baking it into the code your agent just shipped. You don't need a flag management platform, an SDK, or a new vendor relationship. You need one column in a table you already have, and a single if statement that reads it before your feature runs. That's the whole mechanism. Everything else is convenience.

This matters more for AI-built apps than hand-coded ones, because the usual failure mode is different. You ask your AI coding agent to "add the new dashboard" or "turn on the referral program," it ships the code, and now it's live for everyone, immediately, with no way to back out except asking the agent to undo it and redeploy. That round trip can take minutes you don't have when the feature is misbehaving in front of real users.

What a Feature Flag Actually Is

Strip away the branding and a feature flag is a stored value your app checks before running a piece of code. That's it. It can live in:

• A column in your database (feature_enabled on a settings row, or a per-user beta_access column)

• An environment variable your hosting platform reads at startup

• A config file your app loads on each request

Commercial flag tools add a dashboard, audit logs, targeting rules, and analytics on top of this. Useful once you have a team and a real support burden. Not useful when you're one person shipping with an AI agent and just need a way to turn something off without a deploy.

The Simplest Feature Flag: a Database Column

Here's the worked example. Say your AI-built app has a users table, or a single-row app_settings table if you don't want a per-user flag yet. You want to ship a new "AI summary" feature but you're not confident in it.

Add a boolean column: summary_feature_enabled, default false. Your backend code, wherever it renders or triggers the summary feature, checks that column before doing anything else. If it's false, the old behavior runs (or nothing runs). If it's true, the new code path fires.

The part that actually matters is how you ask for it. Vague requests to an AI coding agent produce vague implementations. Instead of "add a feature flag for the summary feature," be specific about the mechanism:

• "Add a boolean column called summary_feature_enabled to the app_settings table, default false. In the API route that generates the summary, check this value first and return the old response unchanged if it's false. Add an admin-only endpoint or script I can run to flip it to true without redeploying."

That last sentence is the part most people skip, and it's the difference between a real feature flag and a flag you can only toggle by editing code and pushing again. Ask explicitly for a way to change the value that doesn't require a deploy: a small admin page, a database console query, or a CLI script. If your agent gives you a flag that only changes via a code edit, you haven't built a feature flag, you've built a slower way to comment out a function.

Rollout Percentage in an AI App Without a Flag Service

Once the boolean version works, a rollout percentage AI app pattern is a small extension, not a rewrite. Instead of a boolean, use an integer column: summary_feature_rollout_pct, ranging 0 to 100.

At request time, hash something stable about the user (their user ID works well) into a number between 0 and 100, and compare it against the stored percentage. If the hashed value falls under the threshold, they get the new feature. Same user, same hash, every time, so people don't flicker between old and new behavior on every page load.

Ask your agent for this directly: "Change summary_feature_rollout_pct to an integer, default 0. In the check, hash the user's ID to a number 0-99 using a consistent hash, not Math.random(), and enable the feature if that number is below the stored percentage. Give me a script to update the percentage."

The "not Math.random()" instruction is worth including verbatim. Agents will happily wire up a random check that re-rolls on every request, which means the same user sees the feature on one page load and not the next. That's not a rollout, that's a bug that looks like a rollout.

Toggle Features Without Redeploying: Environment Variables

A database column is the right call when the flag needs to vary per user or by percentage. When it's a single global switch, an environment variable is simpler and needs no schema change at all.

Most hosting platforms (Vercel, Render, Railway, Fly.io) let you change an environment variable and either restart the app instantly or pick it up on the next request, without touching your code or running a build. Ask your agent to read a variable like FEATURE_SUMMARY_ENABLED and gate the code path on it, defaulting to false if the variable is missing. That default matters: an unset environment variable should always mean "off," not "on," so a misconfigured deploy fails safe instead of accidentally launching something.

The tradeoff versus a database column is speed of change. Flipping an environment variable usually means a redeploy or restart on your host, which takes longer than an admin page hitting a database. For anything you expect to toggle often during a launch, the database column wins. For a flag you'll set once and rarely touch, the environment variable is less to build.

The Kill Switch Failure Mode

This is the mistake that actually costs people sleep. Someone ships a feature flag AI app pattern correctly, boolean column, clean check, works in testing. Then the feature goes live, something breaks under real traffic (a third-party API rate-limits them, a query times out, an edge case in real user data nobody tested), and there's no fast way to turn it off.

Why not, if there's a flag? Because the flag was built to turn the feature on, and nobody built a way to turn it off in an emergency. Common versions of this:

• The toggle only works through an admin UI that itself depends on the broken feature, or requires a login flow that's slow to reach at 2am

• The "off" switch is a script that has to be run locally, and whoever's on call doesn't have the environment set up

• The flag check was added to only one of three places the feature triggers from, so switching it off doesn't fully stop the behavior

The fix is to test the off switch before you ship the feature, not after it breaks. When you ask your agent to build the flag, ask it to also show you, in plain terms, exactly what you'd do to disable the feature in under a minute if it started failing in production. If the answer involves a deploy, more than one step, or a tool you don't have open right now, that's not a kill switch, that's a to-do list you'll be reading while users are already affected.

A genuinely fast kill switch is a single value flip you can do from your phone: a database console query, or a one-click toggle on an admin page that doesn't depend on the feature it's controlling.

When to Graduate to a Real Flag Service

A column and a check will comfortably cover one person or a small team through most of a product's early life. It's worth moving to a dedicated flag service once you have several flags interacting, need to target flags by user segment beyond a simple percentage, want an audit trail of who changed what, or have more than one person who needs to flip flags without touching the database directly. Until then, the homemade version is not a lesser version, it's the appropriately-sized one.

Feature flags are one piece of a bigger discipline. If you are setting up the rest of your stack, the full guide to building an app with AI covers the decisions that come before this one, and the same on/off pattern described here works just as well when you are adding webhooks to an AI-built app.

The kill switch habit extends past flags too. It pairs naturally with rolling back a bad AI coding agent change when a deploy goes wrong, and with giving your AI coding agent read-only production access by default, so the blast radius of any single mistake stays small.

FAQ

Do I need a third-party service to add feature flags to an AI-built app?

No. A boolean or integer column in your existing database, checked before the feature code runs, is a complete feature flag. Third-party services add dashboards, targeting rules, and audit logs, which matter once you have a team, but they're not required to get the core behavior working.

How do I do a percentage rollout without a flag platform?

Store a percentage (0-100) instead of a true/false value, then hash a stable identifier like the user's ID into a number in the same range and compare it against the stored threshold. Use a consistent hash, not a random number generator, so the same user gets consistent behavior across requests.

What's the safest way to toggle features without redeploying?

A database value you can change through an admin page or a direct query is faster than an environment variable, which usually needs a restart or redeploy on most hosting platforms. Whichever you use, make sure the "off" state is the default when the value is missing or unset.

What's the most common mistake when adding feature flags to an app built with AI?

Shipping a flag that can turn a feature on but has no fast, tested way to turn it back off. Test your kill switch before the feature goes live, not after it breaks, and make sure disabling it doesn't itself depend on the feature working.

Should every feature in my app have a flag?

No. Flags add a branch to test and a value to track, so they're worth the overhead for anything risky, expensive, or unproven, new integrations, AI-generated content, anything touching payments, not for a settings page tweak nobody will ever need to roll back.