Fulcrum Settings Laravel Package

Product Decisions This Supports

• Feature delivery without deploy coupling — the flagship decision. Unlike a plain settings table, this package bundles a rule engine: ordered targeting rules evaluated against an evaluation context (authenticated user, tenant, geo, browser, custom attributes), with first-match-wins resolution and a default fallback. That means a PM can answer "can we turn this on for internal testers only next Tuesday without a release?" with yes. That is a roadmap-velocity decision, not just a technical one.
• Gradual rollout and risk-managed launches. Percentage rollouts use consistent hashing for stable bucketing, so a user stays in the same cohort across requests. This lets us ship risky surface to 5% → 25% → 100% with a kill switch, and it's the difference between launching on a Thursday and launching on a Monday. For any feature where a bad launch has support cost or revenue exposure, this is the deciding capability.
• Build vs. buy on an expensive, undifferentiated layer. The alternative is a bespoke settings + feature_flags + rules + cache-invalidation subsystem. That build is deceptively large: typed values, polymorphic ownership, rule ordering, cache keying by context, worker-safe state. None of it is differentiated. Adopt, and redirect that squad to product surface.
• Enterprise and tenant tier enablement. Global defaults with per-tenant and per-user overrides is the exact primitive needed for white-labeling, admin-editable operational config, plan-based capability gating, and "enterprise customers configure their own policy" roadmap items. Note the distinction from a per-tenant settings table: overrides here are scoped and conditional, so "premium segment gets 20% discount, everyone else 5%" is one record, not a branch in code.
• Config changes as an operational lever, not an engineering ticket. Admin-editable settings that change without a deploy reduce on-call load and shorten incident response (flip maintenance banner, throttle rate limit, disable a noisy integration). The masked()/encrypted setting type extends this to third-party credentials, which is often the moment a PM realizes settings infrastructure is also a secrets-management conversation.
• Settings-as-migrations is a governance decision worth naming. Defining settings and rules in versioned, idempotent migration files (upsert) rather than hand-editing rows in an admin UI means environment parity is reviewable in code review. This is the difference between "prod and staging silently diverged three months ago" and "the diff tells you." If we plan to let non-engineers edit settings in production, we should decide now which keys are code-owned and which are operator-owned — the package supports both, and mixing them without a policy is how config drift happens.
• Use cases to prioritize: staged feature launches, internal/beta targeting by attribute, plan- and segment-based capability gating, per-tenant operational tuning (rate limits, quotas, display defaults), and admin-editable settings with audit-relevant change history. Use cases to deprioritize: high-volume experimentation with statistical analysis, multi-variate tests needing significance calculation, and sub-second propagation to edge clients — this is a database-backed app-layer resolver, not an edge flag service.

When to Consider This Package

Consider adoption when:

• The stack is Laravel 12 or 13 on PHP 8.3+. This is a hard gate, not a preference. v2.0.0 was a breaking release that explicitly dropped Laravel 11. If we are still mid-migration on Laravel 11, this package is not adoptable today — and that's a fact worth surfacing to whoever owns the framework upgrade roadmap, because it makes the upgrade a dependency for feature-flag capability rather than a background chore.
• We need conditional, not just per-entity, configuration. If every requirement is "tenant X gets value Y," a plain settings table suffices and this is overkill. The value appears the moment requirements include who (segment, attribute, cohort) and how much (percentage rollout).
• Feature flagging is on the roadmap within two quarters. Adopting before the first flag is needed is cheaper than retrofitting a homegrown flag check into code that already assumed static config.
• Engineering would otherwise build this. Run the build-vs-buy math honestly: a rules engine with priority ordering, consistent-hash bucketing, context-isolated caching, and worker-safe state is weeks of work plus permanent maintenance. Buying it is a straightforward call.
• We can live with community-package support terms. Apache-2.0 means we can fork if the vendor disappears. That is the mitigation, and it should be stated as such rather than assumed.

Look elsewhere when:

• Real experimentation is the goal. No significance testing, no multi-variate analysis, no experiment dashboards. If the ask is "which onboarding flow converts better," we need an experimentation platform; this package can run the flag but not answer the question.
• Non-Laravel services need to read the same flags. This is a PHP package. A polyglot estate (Go services, edge workers, mobile clients) needs a flag service with SDKs, or we accept that flags only apply to the Laravel app — a scoping decision to make explicitly, not discover later.
• Settings are actually deployment configuration. If a value never changes without a deploy anyway, environment config is simpler, safer, and has no cache-invalidation failure mode.
• Compliance requires approval workflows and immutable audit trails out of the box. Confirm what change history exists before committing; if the answer is "not really," budget for a wrapper and an approvals layer, and put that cost in the business case rather than treating it as free.
• Maturity risk is disqualifying. Three GitHub stars and a single small vendor is a real signal about bus factor and long-term support. If the org requires vendor SLAs or a security review with a named counterparty, this fails procurement regardless of technical merit. The honest read: technically credible, commercially tiny.

Release-specific note for the adoption decision: the 2.0 line is recent and already breaking (Laravel 11 dropped). That is a young package moving fast — good for capability, bad for stability guarantees. Pin the minor version, budget recurring patch-review time, and don't adopt expecting a frozen API. The v2.0.1 fixes also imply a prior correctness issue in polymorphic resolution that could have written settings under mismatched type identifiers; if we ever ran an earlier version in a shared environment, treat existing rows as suspect and audit before trusting them.

How to Pitch It (Stakeholders)

For executives: This is a small, Apache-licensed Laravel package that gives us two capabilities we would otherwise build: admin-editable configuration per customer, team, or user, and rule-based feature flags with percentage rollouts. Concretely, it lets us launch features to 5% of users and widen the rollout without a deploy, and lets enterprise customers configure behavior without engineering tickets — both already on the roadmap. Buying it is materially cheaper than a platform build, and the data stays in our own database under our own license, so the exit cost is low: worst case, we fork. The two things to be candid about: it requires Laravel 12+ (so it's coupled to our framework upgrade timeline), and the vendor is a very small open-source project with no commercial support — which is why the forkability and the low switching cost are the actual risk story, not the feature list.

For engineering: Fulcrum Settings is a Laravel-native settings and flag layer with typed values, polymorphic ownership, an ordered rule engine, consistent-hash percentage rollouts, encrypted/masked values, and context-scoped caching. Settings and rules are defined in versioned, idempotent migrations, so environment parity is reviewable in code. The material constraints: PHP 8.3+, Laravel 12/13 only — v2.0.0 was a breaking release that dropped Laravel 11, so adoption is gated on our framework upgrade. Before we commit, we need four questions answered, because the changelog raises them and doesn't close them: (1) is the polymorphic lookup indexed on (settingable_type, settingable_id, key), and does the cache key include the evaluation context — the 2.0.1 fixes suggest context-isolation bugs existed, and stale caching here fails silently rather than loudly; (2) is there a backfill for rows written under 2.0.0, or is remediation on us; (3) what change history exists for settings edited outside migrations, since that's our audit surface; (4) does the resolution path hold up under our expected settings volume and worker model — the 2.0.0 fixes reference worker state cleanup and tenancy listener context, which reads like queue-worker correctness work that is still settling. Acceptance test is a full write → read → override → rollout-bucket → delete cycle against a real morph-mapped model in staging, with the settings cache cleared on deploy, promoted to one low-traffic tenant first.