Spike PDEV-679 — Feature Flag System

Spike to evaluate a feature-flag system for the Arda platform: gate functionality per tenant / user / environment and toggle features on and off without a deploy.

Ticket: PDEV-679 (captured from product brain-dump; to be fleshed out in triage) Branch: david/pdev-679-feature-flags Author: David Quintanilla Last updated: 2026-06-16

Goal

Ship code that is dormant in production and reveal it to a chosen audience — a single user for a demo, a beta cohort, or a specific tenant that gets a bespoke module — and flip it live or dark from a dashboard, with no rebuild and no redeploy.

Artifacts

• Spike Analysis — verified current-state findings, industry patterns, build-vs-buy, the PostHog-first recommendation, and a proof-of-concept plan.
• Code Sketch — concrete starting-point code: the shared flag registry, the Kotlin FeatureFlags interface + PostHog local-eval impl, and the React hook + BFF bootstrap route.

Headline conclusions

• There is no RBAC to build around — this is greenfield. The backend enforces authenticated-or-not plus tenant scoping; the custom:role claim is read nowhere. See the analysis for the code evidence.
• Recommendation: adopt PostHog feature flags (already in the stack) behind a thin internal abstraction, evaluating in the frontend, the BFF, and the Kotlin backend. Build a bespoke bitemporal flag service only if audit-grade governance later demands it.
• Separate release toggles from entitlements. “Show feature X to this user” and “tenant Y owns custom module Z” have very different lifespans; conflating them is the classic source of flag debt.