Grant customers early feature access without engineering

Build me an internal app that my support and customer success team opens whenever a customer asks for early access to a feature, so nobody has to ping engineering. It is a customer feature access console backed by LaunchDarkly and HubSpot, with change notes going to Slack.

The main screen is a customer search. A rep types a company name or domain and the handler calls HubSpot Search Companies to return matches. Picking an account calls HubSpot Get Company to pull the full record, and the account header shows company name, domain, plan tier, renewal date, and the account owner.

Selecting an account opens the access view for that customer. Use LaunchDarkly List feature flags for the project to get every flag with its per-environment configuration and tags, and Get flag status across environments so a rep can see where a flag is live. For each flag, work out whether this customer is currently switched on and how: an individual context target on the flag, membership in a segment that the flag targets, or the default rule. Use List segments to get the segments in the project and environment, and List segment memberships for context instance to resolve which segments this customer's context actually belongs to. Use Get expiring context targets for feature flag to surface anything already scheduled to lapse.

Render this as one row per feature the customer is on, showing the flag name, the variation they are receiving, how they are getting it (targeted directly, through a named segment, or through the default rule), and the expiry state. Default the whole view to the production environment, with an environment switcher available but production preselected. Include a toggle to show all flags in the project rather than only the ones the customer is currently on, so a rep can grant something new.

From the same row a rep can act. Grant or revoke access for the customer with LaunchDarkly Update flag settings for context, which sets a specific variation for that one context. Add or remove the account from a beta cohort with Patch segment, adding or removing the customer's context key from the segment's included targets. Every grant must also set an expiry through Update expiring context targets on feature flag, so trial access cleans itself up on its own. Suggest a default of 30 days in the date picker but let the rep change it.

Each change posts a note to the feature owner's Slack channel using Slack Bot Send a Message. The note says which customer, which feature, what changed, who made the change, the written reason, and the expiry date. Let an admin map each flag (or each flag tag) to a Slack channel in a settings view, with a fallback channel when no mapping exists, and use Slack Bot List Channels to populate that picker.

Persist every change the app makes: timestamp, the rep who made it, the customer, the flag or segment, the direction (grant or revoke), the reason text, and the expiry date. Show this as an activity log on the account so the next person to open the account can see what was already done and why.

Add a Review access button on the account that kicks off a background agent. The agent sweeps every project and environment for that account using List projects and List environments, then walks the flags and segments in each to build a full picture of what this customer is switched on for beyond the environment the rep happens to be looking at. It reads the HubSpot record with Get Company for plan tier and renewal date. It checks LaunchDarkly List audit log entries to establish who granted what and when, including grants made outside this app. It then writes a short access summary back into the app, attached to the account, calling out grants that outlived their trial, grants with no expiry set at all, grants that contradict the customer's plan tier, and anything worth revisiting before the renewal date. The summary lands in the account view under the flag rows, with a timestamp and a rerun button.

Bake in these rules. Default to production everywhere, and never let a rep act on an environment without seeing which one they are in. Block any flag tagged internal: those rows are visible but locked, with a short note saying why, and no grant or revoke action is available on them. Require a written reason on every grant and every revoke, with the submit button disabled until the reason is filled in, and carry that reason into both the Slack note and the activity log. Show expiry in plain language, like expires in 12 days, expires tomorrow, expired 3 days ago, or no expiry set, rather than raw dates, with the exact date available on hover.

API notes for building this. LaunchDarkly auth is the raw token in the Authorization header with no Bearer prefix, and every request should send LD-API-Version: 20240415. Resources are addressed by human readable projectKey, environmentKey, and featureFlagKey rather than database ids. Targeting changes and toggles are most reliable via semantic patch, which needs Content-Type: application/json; domain-model=launchdarkly.semanticpatch. The API host is region specific and comes from the credential's region field. Expiring context targets are the mechanism behind the expiry date. Standard segments are updated with Patch segment, while big segments need the dedicated big segment target endpoints, so detect which kind a segment is before writing to it.