Core Laravel Package

Product Decisions This Supports

• Modular monolith vs. separate deployables. The module:* command set (module:list, module:enable, module:disable, module:migrate) makes in-app modules a cheap, reversible option: one codebase, features switched on per environment, per tenant, or per edition. This is the package's core product lever — it turns "should this be a service?" into a config decision rather than an architecture rewrite.
• Multi-tenancy strategy. tenancy:install, tenant:create-database, tenancy()->run(), the Tenant/Domain base models, and PreventAccessFromCentralDomains all point squarely at database-per-tenant with a central admin domain. Choosing this package is the tenancy decision. Adopt it only if that model is the roadmap; retrofitting a different isolation strategy later is a migration project, not a config change.
• Edition / tiered packaging. Module toggles plus devanox:license-check enable a free-core-plus-licensed-modules model without maintaining divergent branches. This is the highest-value strategic use and the one worth prototyping first.
• Self-hosted / installable distribution. InstallApp middleware and isAppInstalled() support shipping a first-run installer and gating the app until setup completes — i.e. the "can customers self-host this?" decision, not just managed SaaS.
• Build vs. buy (internally). Rebuilding a module loader, tenant context switching, and license enforcement is multiple engineer-weeks plus permanent maintenance. Inside the Devanox family the package is free, so default to adopting — the open question is governance, not cost.
• Release-train mechanics. Shipping modules dark and enabling them per tenant gives product a progressive-delivery lever without a feature-flag vendor.
• Commercial licensing strategy. The license-check command raises a real product question: do we enforce paid tiers in the product, and what happens offline or behind a customer firewall? That answer must exist before any revenue-bearing deployment.

When to Consider This Package

Adopt when most of these hold:

• You are inside the Devanox project family or contracted to it. The Proprietary License makes this the only clean path; there is no permissive option here.
• Your stack is already, or can immediately be, PHP 8.5+ / Laravel 13.x. This is a hard install constraint — bleeding-edge runtimes mean you upgrade first and alone.
• You need modules, multi-tenancy, and edition licensing as one dependency from one vendor, and prefer one owner over three.
• You are building database-per-tenant SaaS with a central admin domain; the middleware and context API are already shaped for it.
• You want the bundled Blade (core:: namespace) and Livewire admin surface rather than building an admin shell.
• You have audited the global surface — modules(), tenant(), tenancy(), isAppInstalled(), the Core facade alias — against existing application helpers and reserved names.

Look elsewhere, or push back hard, when:

• You need an ecosystem. 0 stars, 0 dependents, pre-1.0 (v0.2.1), single vendor. There are no third-party answers, tutorials, or Stack Overflow threads. Support is a relationship, not a guarantee.
• Your runtime is PHP 8.3/8.4 or Laravel 10–12. Non-negotiable blocker.
• You cannot permit outbound calls for license verification or need signed/offline licensing. Behavior on failure and no-network must be proven before this reaches a paying customer.
• You already have a tenancy approach (row-scoped single DB, or another package's conventions). The base Tenant/Domain models impose a shape you'd have to migrate onto.
• You need to redistribute or open-source any part of the app. Proprietary terms rule it out.
• Maturity is a hard gate. Pre-1.0 with an empty v0.2.1 changelog, README-vs-repo name mismatch (devanox/core vs devanoxltd/core), and no external production references are documentation-quality signals worth escalating before commitment.

How to Pitch It (Stakeholders)

To executives (summary): This is our own platform foundation, not a market dependency. It bundles the three things we currently rebuild on every Laravel product — a module system, multi-tenancy, and license/edition enforcement — into one Composer package. That converts per-project setup work into a shared, versioned asset, and lets us ship a single codebase with features switched on per customer or per tier instead of maintaining separate builds. It also gives us an in-product licensing hook, which is the mechanism behind any paid-edition or partner-distribution model. The cost is structural: it's pre-1.0, single-vendor, proprietary, and pinned to PHP 8.5 / Laravel 13, so it is a platform commitment rather than a drop-in library. Either we back it with named ownership and an upgrade/support agreement, or we should not put revenue-critical licensing behind it. Recommendation: adopt as the standard for new Devanox Laravel work, pilot it in one product, and gate wider rollout on a documented review of the license-check behavior for success, failure, and no-network.

To engineering (talk track): Integration is idiomatic Laravel — publish tags for config/migrations/views/lang/assets, Artisan commands for module lifecycle and tenancy, a tenancy()->run() context API, and middleware already registered into the HTTP kernel. The work is not installation; it's four decisions:

1. Read the source as the spec. The README stops at commands, so confirm the module discovery contract and manifest shape (modules/ path, Config/config.php per module) directly from vendor/devanoxltd/core before anyone writes code.
2. Fix the module convention up front. One module per bounded context, modules own their migrations and routes, modules communicate via events or contracts — never by importing each other's concrete classes.
3. Fence the global surface. Wrap modules(), tenant(), tenancy(), and the Core alias behind our own thin adapters so helpers can't leak into other packages' service providers and boot order stays predictable.
4. Prove licensing in staging. Test success, failure, and no-network paths before enabling it anywhere real.

Risks to state plainly: single-vendor bus factor; no external dependents to lean on; changelogs that don't describe behavior changes; an eng locale quirk requiring APP_FALLBACK_LOCALE=eng or a published override. Ask for a version-pinning policy and a fork-and-patch contingency — a zero-adoption proprietary package should be treated as vendored source we may have to maintain ourselves, not a black box we can afford to wait on.