Foundation Laravel Package

Product Decisions This Supports

• Build vs. buy on the back-office layer. Every roadmap eventually hits the same fork: hand-roll roles, permissions, menus, resource routing, and a module registry, or assemble Laravel Nova/Filament + Spatie permissions + a homegrown loader and own every seam between them. Orchestra Foundation is a third option — one pre-integrated platform that ships the module model, ACL, theming, admin scaffolding, and settings as a designed whole. This package turns that fork into something you can evaluate and price rather than debate abstractly. Weight the evidence honestly: zero visible dependents and a low composite score mean you are evaluating an architecture and its source, not a validated market choice.
• Modular monolith vs. single-team codebase. The extension model is the only product-relevant differentiator here. If the roadmap genuinely includes separate teams or partners shipping capabilities without touching core, per-client white-labeling, or a future extension marketplace, that is a structural fork worth making deliberately and early. If every feature will live in one repo owned by one team, the module machinery is cost without payoff.
• Roadmap sequencing and the "platform" bet. Adopting Foundation is a public statement that the product is a platform with extensions, not an app. That commits you to module governance (ownership, naming, dependency direction), an upgrade cadence you do not control, and a narrower hiring profile than "Laravel developer." It belongs in a recorded ADR, not a Composer line item — reversal cost is a rewrite of structural seams, not a package swap.
• Risk register and vendor-concentration input. Effectively one upstream maintainer, negligible downstream consumption, no commercial support. That belongs in the same conversation as bus factor, hiring pool, and a fork-and-own budget line, weighed explicitly against the build time the platform might save.
• Competitive framing for the admin surface. The real comparison set is Filament, Nova, Backpack, and October CMS. They win on tutorials, hiring pool, support contracts, and currency with new Laravel majors. Orchestra's claim is deeper platform semantics on day one. The PM decision is how much platform machinery the product needs now versus what can be deferred until the module story is validated with real customers.
• Scoping candidate use cases. Internal tooling portals, agency/white-label back ends, legacy modernization where an admin layer and module boundaries already exist conceptually, and architecture-validation spikes where the extension points — not the UI — are the thing under test.
• Setting the upgrade-lock policy. Because the Composer constraint is a hard lock on the Laravel major, this decision forces a policy decision the PM owns: how many months behind current Laravel are we willing to run, and will CI forbid automatic major upgrades. That policy is a business risk statement, not a technical detail.

When to Consider This Package

Consider it when:

• You are Laravel-native and pluggable modules are a genuine product requirement — separate teams or third parties shipping installable features — not just a nice-sounding diagram.
• You want ACL/RBAC, theming, admin scaffolding, and a module loader as one pre-integrated whole, rather than wiring Filament or Nova plus Spatie plus a homegrown loader and owning every seam.
• You are greenfield. This is a skeleton, not a dependency: the viable path is a fresh install with domain logic ported deliberately, or an isolated satellite admin service behind a route prefix and a separate database connection. Grafting it onto an existing production Laravel app is a poor trade.
• You have capacity to own a fork — thin documented patch layer, named internal maintainer, and that name on a calendar before any product code is written.
• Your team already knows the Orchestra lineage, so extension lifecycle, resource routing, and ACL semantics aren't a learning tax stacked on everything else.

Look elsewhere when:

• Your need is mainstream, well-staffed admin tooling with abundant docs, a hiring pool, and commercial support. Filament and Nova win on every operational axis, and most roadmaps are better served by them.
• Your requirement is CRUD plus auth. The platform semantics are pure overhead paid for in upgrade friction and debugging surface.
• You need predictable long-term support. Verify commit cadence, issue responsiveness, and the supported Laravel matrix against tagged releases, not the README, before committing — Foundation histories track specific Laravel majors.
• You are on a fast latest-Laravel track. Meta-frameworks that hook deep into bootstrapping tend to trail new majors; treat the Composer constraint as a hard lock.
• You need multi-tenancy with data isolation guarantees. Module boundaries are not a tenancy story; do not conflate the two.

The gate: a one-to-two week spike that stands up the skeleton, builds one real extension end to end, exercises ACL, confirms the Laravel version matrix, attempts a minor framework bump to measure upgrade cost, and produces a written exit-cost estimate. Default answer is no unless the spike passes and an owner is named.

How to Pitch It (Stakeholders)

To executives. This is an accelerator for one narrow bet: a modular admin platform on Laravel. It hands us extension points, permissions, theming, and an admin surface out of the box, which could save meaningful build time on a platform-shaped roadmap and could unlock a partner/extension story later. The catch is adoption risk. It is a niche package with a single upstream maintainer and effectively no visible downstream usage, so we would be adopting it as an internal fork we own, not a vendor dependency. That changes the math: we buy a head start on architecture and pay for it in maintenance and upgrade ownership. Recommendation: fund a time-boxed spike against the realistic alternative — Filament plus our own module loader. If the spike shows we would otherwise spend more than roughly six engineer-weeks rebuilding module management and ACL, and if the exit-cost estimate says we can walk away inside a sprint, adopt it with a named internal owner and a documented fork plan. If not, take the conventional route; the strategic upside does not justify carrying an unmaintained core.

To engineering. The appeal is architectural, not ergonomic. You get a module model, ACL, theming, and settings as one designed system instead of stitched-together packages — genuinely useful if we intend to let separate teams or partners ship features independently, and hard to retrofit later. The costs are real and should be stated plainly: sparse documentation and examples, a small hiring pool, likely lag on new Laravel majors, and upgrade paths we will debug ourselves inside code that hooks framework bootstrapping. Two things to internalize. First, this is a skeleton, not a library: assume it owns bootstrapping, service provider registration, and often the user model — plan to run it as a whole install or not at all. Second, write the ADR and onboarding doc during the spike and enforce the extension boundary in code review; the most common failure mode is engineers applying native Laravel conventions — policy-based authorization, auto-discovery, Livewire/Inertia layouts — inside a Foundation app, producing inconsistent authorization and duplicated admin chrome. Lean on the four extension points that cover nearly all day-to-day work: extension service providers, Orchestra\Memory for settings, the theme API, and resource-routing scaffolding. Keep domain logic in portable classes so the escape hatch stays cheap.