Modular Laravel Laravel Package

Product Decisions This Supports

• Architecture direction: modular monolith vs. conventional Laravel vs. microservices. This starter codifies one opinionated answer to "how do we keep a Laravel codebase navigable as it grows?" — making it a concrete artifact for that decision rather than a theoretical debate.
• Build vs. buy (or rather, build vs. fork). Adopting a boilerplate means forking and owning it. This package is an input to the decision "do we stand up our own project template, or seed it from an existing one?" It is not a dependency you composer require and upgrade.
• Team topology and ownership boundaries. Module folders map naturally to team ownership, review scopes, and on-call surfaces. If the roadmap implies parallel squads, module boundaries become a staffing decision, not just a code-style decision.
• Convention-setting before feature work. Relevant when kicking off a greenfield product and you want routing, namespacing, and module scaffolding decided once, early, instead of retrofitted under delivery pressure.
• Not a feature enabler in itself. It unlocks no user-facing capability; its value is in velocity and maintainability for the team that owns it. Frame any proposal accordingly — it is an engineering-enablement line item, not a roadmap feature.

When to Consider This Package

Consider it when:

• You are starting a greenfield Laravel product and expect the domain to grow enough that a flat app/ directory will become a liability.
• You want a pre-wired, opinionated reference for how to structure modules — routes, namespaces, migrations, controllers per module — rather than inventing it from scratch.
• You have a small team comfortable fork-and-owning a template, with someone accountable for keeping it current.
• You are evaluating modular Laravel as a pattern and want a working example to react to in a short spike.

Look elsewhere when:

• You need an actively maintained dependency. The last release is February 2023 and the project has low community traction (48 stars), so expect to own all fixes, security updates, and Laravel-version compatibility yourself.
• You want a Composer package with upgrade paths rather than a starter you copy. Evaluate nwidart/laravel-modules or plain Laravel conventions (service providers, domain folders, app/Modules) as lighter-weight alternatives.
• You have an existing application. Retrofitting a boilerplate is impractical; borrow the structure, not the repo.
• You need vendor support, a security cadence, or a large answer base. A 48-star, stale project will not provide them.
• Your team is large enough that boundaries should come from domain modeling, not from a template's folder layout.

How to Pitch It (Stakeholders)

For executives: This is a project starter template, not a purchased library. Adopting it means we copy it into our repo and become its maintainer — there is no vendor, no support contract, and no upgrade path. The cost is engineering time, not licensing. Its benefit is a faster, more consistent first month on a new Laravel codebase; its risk is that we inherit a stale, low-traction codebase and must keep it current with future Laravel releases ourselves.

For engineering: The package is a well-scoped example of a modular monolith in Laravel with minimal ceremony. Treat it as a reference implementation and structural inspiration, not a dependency. Recommendation: run a short timeboxed spike to evaluate the module layout against our actual domain boundaries; if it fits, extract the pieces we want into our own internal template that we control. Do not standardize on the upstream repository without a named owner and a plan for Laravel-version upgrades.

Decision requested: Approve a small, timeboxed evaluation spike. Defer any commitment to adopting it as a long-term baseline until we have a maintenance owner and a comparison against our own template and the more actively maintained alternatives.