Laravel Dev Booter Laravel Package

Product Decisions This Supports

• Build vs. buy (and mostly "build"): This package is a thin convention layer over Laravel's environment checks — a base service provider that splits registrations into prod-only and dev-only lists. The decision it informs is less "should we adopt this" and more "should we codify this pattern at all, and is a 35-star dependency the right vehicle for a ~50-line helper?" For most teams the honest answer is: adopt the pattern, vendor the code.
• Local developer experience / onboarding time: If composer install && php artisan serve currently triggers boot of Elasticsearch, a payment SDK, an observability agent, and a queue worker, new engineers pay that cost on every clone and every fresh container. This package makes the "don't boot prod services locally" rule explicit and repeatable instead of relying on tribal knowledge in AppServiceProvider.
• Cost and blast-radius containment: Prod-only SDKs can leak real API calls, real charges, and real side effects (emails, SMS, webhooks to third parties) when a developer has prod-shaped .env values locally. Gating registration by environment is a cheap guardrail and reduces the "oops, I emailed 400 customers from my laptop" class of incident.
• Environment parity trade-offs: This is a deliberate reduction in parity. The PM decision is whether the speed and safety gains outweigh the risk that a bug only surfaces when the provider is missing — i.e., whether the app degrades gracefully when search, payments, or queues are absent. If it does not, this package hides a defect rather than fixing one.
• Roadmap signal on testability: Needing this package is often a symptom: business logic is coupled directly to third-party SDKs rather than behind interfaces that can be faked. If the roadmap already includes a "contracts + fakes" refactor, this package is a stopgap, not a destination.
• Scope of applicability: Relevant only to apps with genuinely heavy or externally-billing providers. A CRUD app with a database and a mail driver gets nothing from it.

When to Consider This Package

Consider it when:

• You have three or more service providers that are meaningless or expensive outside production (search clusters, payment gateways, feature-flag SDKs, APM/tracing agents, error trackers, SMS/email vendors).
• Local boot time or container start time is a measured pain point, or onboarding docs currently say "comment out these providers to run locally."
• You want the rule to be declarative and reviewable rather than scattered if (app()->isProduction()) calls across providers.
• You are comfortable owning the code: with ~35 stars, a single maintainer pattern, and a score of 0.485, treat this as source you copy, not a dependency you trust. MIT license makes that straightforward.

Look elsewhere or skip it when:

• You have one or two conditional providers — a 10-line AppServiceProvider change accomplishes the same thing with zero supply-chain surface.
• You need parity in CI or integration tests, where the "prod" services must actually be exercised. This package is the wrong axis for that; you want contract tests, fakes, or ephemeral containers (Docker Compose, Testcontainers).
• Your app does not degrade gracefully when a provider is absent — missing bindings will surface as runtime exceptions, and the package will make local runs pass in ways production would not.
• You rely on Laravel Octane or a pre-booted container where provider registration timing matters; verify the mechanism against your runtime before committing.
• You need maintenance guarantees or vendor support. Small single-maintainer packages are fine as utilities and unacceptable as load-bearing infrastructure. Pin the version or fork it.

Migration/exit cost: essentially zero — remove the base class, inline the checks. That low switching cost is the strongest argument for trying it and the strongest argument for just writing it yourself.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a small, free, MIT-licensed utility that lets us keep expensive production-only integrations — payments, search, monitoring, SMS — switched off when engineers run the app on their own machines. The upside is faster developer setup and a hard guardrail against test runs that accidentally hit real vendors and generate real invoices. The cost is a few hours of integration and effectively nothing in licensing. It is not strategic infrastructure; it is a productivity and risk-hygiene tweak. I'd approve it as a small, reversible experiment, and expect the team to fold the pattern into our own codebase rather than depend on a 35-star package long-term.

For engineering: Adopt the pattern deliberately and the package cautiously. Concretely: introduce a base provider that separates prod-only and dev-only registrations, move the heavy SDKs behind it, and measure local boot time before and after. Validate that the app still fails loudly and usefully when a gated provider is absent — a silent success locally that breaks in production is a worse outcome than a slow boot. Given the low star count and single-maintainer profile, plan to vendor the ~dozen lines involved, or at minimum pin the version and add it to the dependency review list. If the real complaint is that business logic is welded to vendor SDKs, treat this as a stopgap and schedule the contracts-and-fakes refactor that makes the whole question moot.