Pincore Laravel Package

Product Decisions This Supports

• Modular monolith vs. microservices: Cross-app autoloading lowers the cost of keeping bounded contexts (billing, catalog, portal, admin) as separate apps inside one deployable. This is the evidence needed to defer a services split — and the cost savings — for another planning cycle.
• Build vs. buy for module scaffolding: Automatic PSR-4 discovery and dynamic namespace registration removes the bespoke Composer plumbing teams usually hand-roll for multi-app repos. Treat this as "buy" for the discovery/loading layer; keep "build" for the domain boundaries themselves.
• Product-line architecture: Supports one codebase serving multiple surfaces (customer portal, back office, API, partner app) that share models and services directly. Relevant to roadmap decisions about launching a new surface without forking the repo or duplicating domain logic.
• Time-to-market on shared-domain features: A feature that touches two apps (e.g., a shared entitlement model consumed by both portal and admin) no longer requires a Composer repositories change and dependency release dance. This shortens the loop between "spec approved" and "shippable" for cross-cutting features.
• Developer environment parity as a delivery risk: Universal relative path discovery across Linux, macOS, and Windows reduces "works on my machine" failures and CI drift — a real input to sprint velocity and onboarding time estimates, especially for teams with mixed OS fleets.
• Use cases to validate against: multi-tenant SaaS with distinct portal/admin apps, agency or product-studio setups shipping many apps on one core, and internal platforms where teams own separate apps but share a domain layer.

When to Consider This Package

Consider adoption when:

• The team is already committed to PHP/Laravel conventions and wants app-level isolation without leaving the ecosystem.
• You have (or credibly expect) three or more bounded contexts that must share models and services — the payoff scales with the number of apps, and is near zero for a single-app product.
• Your engineering fleet is cross-platform (Windows laptops alongside macOS/Linux CI); the portability work directly removes friction you are currently paying for.
• You can accept a framework-level dependency, not a swappable package. This is core infrastructure — adopting it is closer to choosing a platform than installing a library.

Look elsewhere when:

• You need vendor SLAs, long-term commercial support, or an audited dependency supply chain (regulated/enterprise procurement).
• The team is standardized on vanilla Laravel plus nwidart/laravel-modules or similar, and migration cost outweighs the discovery convenience.
• The product is a single deployable app with no credible multi-app roadmap — you would be adopting surface area for no benefit.
• Cross-app autoloading would be used to paper over cyclic dependencies between domains rather than to express clean boundaries. The feature makes coupling cheap to write; that is a governance risk, not an architecture strategy.
• You depend on a long-support Laravel major and cannot track a fast-moving core's release cadence.

Adoption should come with one non-negotiable: a written convention for which apps may import from which. Implicit namespace registration means implicit coupling, and nothing in the tooling will stop it.

How to Pitch It (Stakeholders)

For executives: This release removes manual build configuration every time one part of the product needs to use code from another. In practice that means new cross-surface features ship faster, new engineers get productive sooner, and our Windows and Mac developers stop hitting environment-specific breakage. It strengthens the case for consolidating on one modular codebase instead of splitting into separate services — a decision that would add significant operational cost. The trade-off to acknowledge: we are deepening our dependence on this framework's core, so we should treat it as a platform commitment with a defined owner, not a utility library.

For engineering: Cross-app autoloading dynamically registers sub-app PSR-4 namespaces, so models, portals, and services from sibling apps are usable directly with no composer.json edits or reinstall cycle. Relative-path discovery makes candidate folder resolution portable across all three OSes. Adopt it, but pair it with a dependency-direction rule and a lint/review check — the convenience of implicit resolution is exactly what makes accidental coupling easy to miss until it is expensive to unwind.