Laravel Abtest Laravel Package

Product Decisions This Supports

• Build vs. buy for experimentation plumbing. This package is the "buy/rent" option for the targeting-and-bucketing layer: it removes the temptation for engineers to hand-roll a config('features.x') flag system or an ad-hoc random-split helper that never gets cleaned up.
• Deploy vs. release decisions. Feature flags decouple shipping code from exposing it — supports trunk-based development, dark launches, gradual rollouts, and kill switches for risky changes.
• Roadmap sequencing under uncertainty. Cheap A/B tests let the team validate onboarding copy, paywall layout, or pricing-page variants before committing a quarter to a "winning" design.
• Cohort gating and packaging decisions. Flags can gate beta cohorts, enterprise-only features, or internal dogfooding without branching the codebase per customer tier.
• Sovereignty/hosting decisions. Because ABRouter's server component is open source, the PM can choose SaaS for speed or self-hosting for data residency — a decision point that most experimentation SaaS vendors remove from the table.
• Scope boundary worth flagging explicitly: this decides who sees what. It does not decide whether the result is real. Statistical significance, guardrail metrics, and holdouts still live in your product analytics; the PM owns stitching those two together.

When to Consider This Package

Reasonable to adopt when:

• The stack is Laravel/PHP and the team is small-to-mid with no dedicated experimentation platform owner.
• You need flag toggles and simple A/B splits in one lightweight abstraction, and the team already expects Laravel service-provider/facade ergonomics.
• You want a low-commitment pilot: the free cloud tier plus an open-source server means near-zero procurement friction.
• You intend to abstract it. The integration surface is small enough that wrapping it behind an internal ExperimentService interface keeps the vendor swappable.
• Experiments are short-lived and low-risk (copy, layout, onboarding), not revenue-critical allocation logic.

Look elsewhere when:

• License is a blocker. GPL-3.0 on a PHP dependency is a realistic legal flag for closed-source commercial products and enterprise procurement. If your org forbids copyleft dependencies, this conversation ends here — confirm with counsel rather than assuming.
• You need statistical rigor. Sequential/Bayesian testing, mutual-exclusion layers, holdouts, CUPED, and warehouse-native analysis are the domain of Statsig, LaunchDarkly, Optimizely, GrowthBook, or PostHog. This is not that.
• Evaluation happens on hot paths. Remote evaluation with caching introduces latency and a failure mode that a local-evaluation SDK would not; benchmark before putting it in front of every request.
• Vendor-risk tolerance is low. ~109 stars, a small contributor base, and limited community answers mean fewer Stack Overflow rescues and real bus-factor exposure.
• Polyglot architecture. This is Laravel-specific and the base library is PHP — services in Go, Node, or Python get no coverage.
• Enterprise compliance requirements. SOC 2, audit trails, and granular RBAC are more likely to be satisfied by a mature SaaS vendor; self-hosting shifts that burden onto your own ops team.

How to Pitch It (Stakeholders)

Executive summary. ABRouter's Laravel package lets us ship features dark and run A/B tests with a few lines of code, replacing informal env() toggles and hardcoded rollouts. Cost of entry is effectively zero — a free cloud tier and an open-source server we could host ourselves. Time to first experiment is measured in hours, not a procurement cycle. The honest risks: a GPL-3.0 license that legal will want to review, a small community (~100 stars) and single-vendor reliance, and the fact that it governs exposure, not measurement — we still need our analytics stack to tell us if a variant won. Recommended posture is a scoped pilot, not a platform commitment.

For engineering. It is a thin Laravel wrapper around abrouter/abtest: config file, service provider, facade, and a token plus a stable user identifier to key bucketing. Because the API surface is small, we should wrap it in our own ExperimentService contract on day one so the vendor is an implementation detail. That gives us a one-file swap if we outgrow it.

For the pitch itself. Frame it as a decision reversal cost argument: adopt behind an interface, pilot on non-critical surfaces, and pre-commit to kill criteria — license review fails, we need targeting dimensions it can't express, or the vendor goes quiet for two release cycles. Any of those triggers a swap with no product-facing change, because the interface stays and only the adapter moves.