Setting Up Feature Flags for Clients as a Cloud Consultant

A two-person engineering team inheriting a flag platform needs something they can learn in an afternoon, not a system with an experimentation layer nobody on their side will ever open. Ask what the client's team already uses for deploys and monitoring, and lean toward the platform whose learning curve matches what they've already committed to elsewhere. Ask specifically what tools they already pay for and whether the team has ever configured a third-party SaaS integration themselves; the answer tells you far more about their real readiness than years of experience or team size alone would.

Pick a low-risk change, ideally something already planned, and wire it through the flag platform end to end: SDK call, targeting rule, rollback test. This first flag becomes the reference example the client's team copies for everything after you're gone, so make it a clean one, not a rushed proof of concept.

Write down, in plain language, exactly how someone on the client's team turns a flag off if something breaks at 2am with no consultant on the phone. Include the login URL, who has access, and what the flag actually controls. This single document prevents more support calls after handoff than anything else you'll build.

What the rollback runbook should contain:

• Write the rollback steps in plain language that someone on the client's team can follow at 2am without you on the phone.
• Include the login URL for the flag platform so nobody has to hunt for it during an outage.
• List who has access to the account, so the person on call knows they can actually flip the flag.
• State what each flag controls, so turning it off has a predictable effect on the client's system.

A month or two after handoff, check whether the client's team is actually using the flag platform the way you set it up, or whether it's already drifted into a mess of undocumented flags nobody remembers creating. A short paid follow-up engagement to clean that up is fair, and often catches problems before they become an incident.

A common mistake is quoting a flag-platform setup engagement as if the technical wiring is the whole job, when the handoff documentation and training session are what actually determine whether the client keeps using it. Price the walkthrough session and runbook as their own line items, not an afterthought bundled into the last day of the engagement.

A setup built for a two-person team, simple targeting, one shared project, may not hold up once that client hires a third or fourth engineer making concurrent changes. Flag this explicitly in your handoff document as a known limit, so the client knows to call you, or budget for a review, once their team crosses that threshold rather than discovering the gap the hard way.

Without a specific scope, a client can reasonably expect you to keep tuning targeting rules and cleaning up flags indefinitely, while you're trying to close out the engagement and move to the next client. Write the flag-platform setup as its own deliverable with a defined end state, one working flag, one documented runbook, one trained team member, rather than an open-ended commitment folded into a broader consulting scope.

Some clients, after seeing the setup work, will ask you to stay on as an ongoing flag administrator rather than fully taking it over themselves, which is a legitimate business decision but a different engagement than the one you originally scoped. Price that as a distinct retainer with its own scope, response-time expectations, and off-boarding plan, rather than letting an open-ended favor quietly become unpaid ongoing support.