Feature Flags Api Laravel Package

Product Decisions This Supports

• Build vs. buy for flag delivery: This package is a presentation adapter — it exposes feature-flag state over an API rather than implementing evaluation, targeting, or storage. It supports a "compose, don't buy" decision: keep the flag engine in-house (or in an existing domain module) and use this as the thin HTTP contract layer instead of paying for LaunchDarkly/Unleash/Split.
• Decoupling release from deploy: Primary product use case is progressive delivery — percentage rollouts, beta/entitlement gating, kill switches — delivered to web, mobile, or partner clients through a stable JSON contract.
• API surface and contract decisions: Forces explicit choices on client-side vs. server-side evaluation, response shape/versioning, cache TTLs, and whether flags are polled or pushed. Good leverage point for defining an internal flag API standard before multiple teams invent their own.
• Modular monolith boundaries: If the team is on the Liberu modular Laravel stack, it validates keeping transport/presentation concerns separate from flag domain logic — a reusable pattern for other modules (billing, entitlements, config).
• Roadmap sequencing: Low-cost enabler for experimentation, per-tenant targeting, and migration cutovers. It does not deliver an admin UI, audit trail, or SDKs — so roadmap items for those remain open and should be scoped separately.
• Vendor-risk decisions: With 0 stars, 0 dependents, and a NOASSERTION license, this is best framed as an internal glue decision (adopt/vendor/pin) rather than a platform bet.

When to Consider This Package

Consider it when:

• You are already building on the Liberu modular Laravel ecosystem and want a consistent adapter pattern.
• You need only the presentation/API layer — you already own (or are building) the flag evaluation, storage, and targeting logic.
• You want a JSON flag endpoint for SPAs, mobile clients, or internal services without designing the contract from scratch.
• You are willing to vendor the code, pin the version, and wrap it in your own auth, rate limiting, caching, and contract tests.
• The team accepts single-maintainer, pre-adoption risk and can absorb a 1–2 day replacement if it stalls.

Look elsewhere when:

• You need the actual flag engine: targeting rules, percentage rollouts, audit logs, approval workflows, or an admin UI. This package is not that.
• You need SDKs, edge/CDN evaluation, or high-availability flag serving at scale.
• License clarity is a blocker — NOASSERTION must be resolved by legal before any production dependency.
• You require community support, security responsiveness, or provenance (0 stars / 0 dependents means no social proof and no downstream testing).
• Release hygiene is a concern: the listed last release (2026-10-26) is anomalous/future-dated — verify tags and changelog before trusting the version line.
• Your stack is not Laravel/PHP or not aligned to the Liberu module conventions; the adapter value collapses outside that context.

How to Pitch It (Stakeholders)

For executives: This is a small, zero-cost adapter that lets us serve feature flags we already own through a clean API, so we can ship behind toggles and run gradual rollouts without adding a vendor contract. It is not a platform purchase and not infrastructure — it is internal glue. The trade-off is maturity: zero adoption, a single maintainer, and an unclear license mean we should treat it as a short-term accelerator, not a dependency we build a roadmap on. Expected value is speed-to-first-flag; expected downside is a one-to-two-day replacement if it is abandoned.

For engineering: Thin presentation adapter for a Laravel modular stack; it does not evaluate flags, store them, or provide targeting — you keep the domain module. Recommended posture: spike and vendor it, pin the release, add contract tests around the response shape, and put our own authorization, rate limiting, and caching in front. Do not let it become the system of record for flag state, and do not expose it publicly without an auth and caching layer. If the license cannot be resolved, hand-rolling an equivalent controller and API resource is a small, well-understood effort — so the decision is reversible either way.