If a change to your website or web app, such as a new enquiry form, goes live for every visitor at once and you find out it broke from a drop in leads, this is for you. It is not for a site built on something other than Next.js or SvelteKit (your developer can tell you in one line: the project's package.json lists next or @sveltejs/kit), and not for a company whose platform team already runs flags. A feature flag puts the change live for a slice of visitors first, so you can watch it, then widen it or switch it off in seconds, without a new release.
What does the Flags SDK do, and what does it not?
The Flags SDK lets you define flags in your own code and read them in pages and middleware. Vercel calls it "a free, open-source library that gives you the tools you need to use feature flags in Next.js and SvelteKit applications." It "works with any flag provider, custom setups, or no provider at all."
The detail that matters for the bill: "Flags SDK is a library, not a hosted service." There is no runtime API to call and nothing to pay for the library itself. The npm package is MIT licensed.
For your developer, in one paragraph: each flag has a name and a decide function that returns its value, and it can read the request, such as a cookie or the visitor's country. For pages that are built ahead of time, a precompute pattern builds both versions in advance, so adding a flag does not slow the page down.
What it does not do: it is named for Next.js and SvelteKit only. If your site runs on another framework, this is not your tool, and we would not plan around it.
Do you need a flag provider at all?
Not on day one. Our rule: decide flags in code while only developers change them. Add a provider when someone outside engineering must change who sees what, without a pull request.
A flag decided in code is a line in a file. Changing it means a commit and a deploy, which is fine when the developer is the one watching the release. It stops being fine when the marketing lead wants to widen a test at 9 pm on a launch day.
That is when a provider earns its keep: a dashboard where a named person changes who sees what. The SDK works with Vercel's own and with the main independent providers, such as LaunchDarkly and Statsig. Vercel Flags is the one built into the platform: targeting rules, segments, splits and environments in the dashboard, "available on all plans".
There is a middle step. Flags Explorer, in the Vercel Toolbar, lets a person on your team switch a flag on for themselves only, without a code change. That is an override: it is how a reviewer sees the new version on the live site before any visitor does.
What does it cost to run?
The SDK costs nothing. Vercel Flags, if you use it, is billed per flag request. As of 16 October 2026:
How requests are counted decides the bill. A flag request is an application request that reads a source project's flag configuration. With one shared Flags client, 10 flags from one source project in one request count as one. The same flag read 10 times counts once. Flags from two source projects count as two. One page view can make several application requests, and each one counts.
So the arithmetic is simple: a site that makes one million flag-reading requests a month on Pro pays 1,000 × $0.03, which is $30. That is our sum from Vercel's price, not a quote. Hobby is for non-commercial, personal use only, so a business site starts on Pro, at USD 20 a month with one deploying seat and USD 20 of usage credit; extra deploying seats are USD 20 and viewer seats are free. For the sample, the plan plus the flags come to USD 50 a month (about AED 184). The usage credit may cover part of the flag line; we count the full price so the sum stays on the safe side. Add USD 20 for each extra deploying seat, such as your agency's.
To find your own number, do not guess from page views. Flag evaluations show in Runtime Logs, so your developer can count a week of flag-reading requests and multiply it out before you switch Vercel Flags on.
The cost to watch is not that line. It is flags nobody removes. Both active and archived flags count toward the flag limit, and every old flag is a branch in the code someone must read.
Can a flag pick the model behind an agent?
Yes, if your web app has an AI assistant in it. A flag's value does not have to be on or off: the Flags SDK reference shows a flag with three options. A route that calls a model can read a flag that returns the model's name, and send a small share of requests to a cheaper one. The SDK's reportValue records which value each request got, so you can compare cost and results per version. Write down, before the stage starts, how many finished tasks you need before you widen and the quality score that switches it off.
What do you tell a security questionnaire about flags?
Two answers, both from the docs. Where the data goes: flags decided in code keep visitor details inside your own function, and a provider evaluates against the context you give it, so give it only what targeting needs and no personal data. Vercel Flags syncs each project's flag configuration to Vercel's edge network, and Vercel has no region in the UAE or Saudi Arabia, so a flag should never carry a customer record.
Who can change a flag: with flags in code, whoever can merge a pull request, and the Git history shows who changed what and when. With a provider, check its access roles and change history before you sign. Vercel's team audit logs are an Enterprise item.
A sample answer to adapt: "Feature flags are decided in our own code. Changes go through a reviewed pull request, recorded in Git. No personal data is passed to the flag service." The rest of a questionnaire, and which answers Vercel's own reports give, is in our security questionnaire post.
How does a staged release work for a brokerage form?
Here is a worked example, not a client. A real estate brokerage in Dubai wants to add a WhatsApp opt-in to the enquiry form on its listing pages. The form feeds Salesforce, and the form is where the leads come from, so a broken version costs real enquiries.
- 01Ship the new form behind a flag, off for every visitor. The old form stays live.
- 02Turn it on for the team only with Flags Explorer. Submit test enquiries and check each one reaches Salesforce with the opt-in field filled.
- 03Turn it on for 10 percent of visitors. Compare enquiries per listing view with the old form until each side reaches the count you wrote down before the stage.
- 04Widen to 50 percent, then everyone, if the numbers hold. Switch the flag off at once if they drop.
- 05Delete the old form and the flag in the same pull request.
The percentages are ours, picked for a page with steady traffic. On a site with a few hundred enquiries a month, a 10 percent stage takes weeks to say anything. There, test with the team through Flags Explorer, then go straight to 50 percent and watch every enquiry. Vercel Flags can run the widening on a schedule: progressive rollouts, added on 11 May 2026, move a change through stages, "each stage has a target percentage and a duration", from the dashboard or the vercel flags rollout command.
The check at each stage is the point. Flag evaluations show in Runtime Logs and can tag page views in Web Analytics, so you can see whether the new form changes behaviour. The test that matters most sits outside Vercel: did each enquiry land in Salesforce with an owner? Each change in this example is checked on a preview first, the way previews for every change describes.
What goes wrong with flags?
Three failure modes follow from how flags work. Flags that outlive their release, because nobody owns the removal. Flags that hide a change from the reviewer, because nobody turned them on in the preview. And flags read in many separate requests on one page, which multiplies the request count for no gain.
None of these is a tool problem. Each one is fixed by a rule written before the first flag.
What do you decide before the first flag?
Write these down, in one place, before anyone adds a flag:
- 01Who owns each flag, by name, and the date it gets removed.
- 02Who may change targeting: developers only, or marketing and sales too. That answer picks code or a provider.
- 03What you watch at each stage, and the number that switches it off.
- 04Where flag reads happen, so one page does not count many times.
We are not a Vercel partner, and the job picks the stack: a site on a framework the SDK does not name gets a different answer. For the wider picture, see our Vercel overview.
If your site changes once a quarter, or every change is small enough to roll back in minutes, you do not need flags yet. If it still runs on an old server, flags come after the move; our hosting page sets out what a move involves, and whether it needs a rebuild. A new form is also where bots and junk leads land, so check it the same week: our post on spam leads and BotID covers that side.
We call the method Preview every change: nothing reaches a visitor that nobody has seen first on a preview link, a copy of the site only your team can open. If a change can cost you leads, send us the page and how it changes today. The written assessment is free, and it says whether your site needs flags, a provider, or neither. A flag on one form may need no build week at all if your developer sets it up; the assessment says which. The first build week is a fixed AED/SAR 14,900, credited in full if you sign the build within 60 days, and our Run plans cover the upkeep after launch.
