Feature Flags for IT Consultancies Managing Many Clients

• Do changes to your client portal or ticketing system require a full redeploy to reach production

• Have you ever rolled back a change because it broke one client's workflow while it worked fine for others

• Does your team currently rely on environment variables or config files to gate features, spread across several repos

• Would your account managers benefit from knowing exactly when a change went live for a specific client

If you checked more than one box, a flag platform will save real time. If you checked none, you likely don't need one yet.

Consultancies often build one shared portal codebase serving every client, then discover that a targeting rule meant for one account accidentally matched another because the attribute they keyed on (say, company size) wasn't unique enough. Key targeting rules on the client's tenant ID, not a descriptive attribute, and test the rule against a staging tenant before it ever touches a real client.

Consulting firms have more staff turnover on individual accounts than product companies do, since consultants rotate between clients. A flag with no documented owner becomes a mystery six months later when someone new inherits the account and finds a dozen flags they're afraid to touch. Require a one-line description and an owner field on every flag at creation, in whichever platform you pick.

LaunchDarkly's straightforward targeting and audit log fit a consultancy's need to know exactly what changed for which client and when, which is often the first question an account manager asks during an escalation. Split's metric-linked experimentation is more useful if you're running your own internal tools where you can define a clear success metric, less so for client-facing portals where the client defines what success looks like.

Some clients, usually larger ones or those with strict data-handling requirements, will insist on a fully separate environment rather than a shared multi-tenant setup. Check whether your flag platform supports separate projects or environments within one account for exactly this case, which is usually cheaper than a fully separate account while still giving that client the isolation their contract requires.

Decide up front whether flag platform licensing is a pass-through cost to clients or a firm overhead, and be consistent across engagements rather than deciding case by case, which tends to create friction when one client learns another got a different arrangement. Most consultancies fold it into overhead once the client count is high enough that a la carte billing isn't worth the administrative cost.

A client in a regulated industry may hand your consultancy a list of requirements, data residency, specific access-control rules, retention periods for change logs, that neither LaunchDarkly nor Split satisfies automatically out of the box. Get that list before the engagement starts, not after you've already targeted flags for that client, since retrofitting a compliant setup around live production flags is far more disruptive than building it in from the first configuration.

A consultancy fielding an urgent overnight call about a client's portal needs whoever is on call to actually have flag access and know how to use it, not just the engineer who happens to be awake and most familiar with that client's setup. Rotate on-call responsibility with a short, current cheat sheet for each active client's most critical flags, so an escalation doesn't stall while someone tracks down the one person who remembers how a given flag works.