Hyn Nova Laravel Package

Product Decisions This Supports

• Build vs. buy for tenant administration. This package is essentially a pre-built Nova back-office for tenant CRUD — creating tenants, editing their metadata, and listing them from an admin panel. If your roadmap includes "ops needs a way to manage tenants without engineering involvement," this is a candidate to buy (adopt) rather than build a bespoke admin UI.
• Multi-tenant SaaS foundation decisions. Adopting this is a de facto commitment to hyn/multi-tenant as your tenancy engine. That is the real product decision here: the package itself is thin glue, but it signals your tenancy architecture for the foreseeable future.
• Internal tooling scope. Useful for deciding whether to invest engineering time in a custom Nova tool versus shipping a tenant-management surface in days. It bounds the "minimum viable admin" feature set so you can defer richer provisioning, billing hooks, and self-serve flows.
• Feature sequencing for tenant lifecycle. Because the package covers admin-side tenant management, it lets you sequence the roadmap as "internal managed onboarding first, self-serve provisioning later" — a common SaaS go-to-market progression.
• Use cases it directly unlocks: internal back-office tenant management, support/ops workflows for tenant CRUD, and demos/prototypes of a multi-tenant product where the admin surface isn't the differentiator.

When to Consider This Package

Consider it when all of the following hold:

• You are already committed to hyn/multi-tenant (or are choosing it deliberately), and this is the matching first-party Nova companion.
• You already own or plan to buy a Laravel Nova license — Nova is a paid product, and this package is worthless without it.
• Your need is internal/admin-side tenant management only, not customer-facing self-serve provisioning.
• You value time-to-admin-UI over long-term ecosystem support, and your team is comfortable owning a small, low-community dependency.

Look elsewhere when:

• Greenfield multi-tenancy. The hyn ecosystem has largely been superseded in the community by stancl/tenancy; starting here bets your architecture on a narrower-maintained base. Prefer the mainstream engine and build/pair admin tooling around it.
• You don't have (or won't buy) Nova. The dependency cost is a license, not just a Composer package — evaluate Filament-based or custom admin alternatives.
• Production-critical, long-lived dependency. With ~12 stars and a low health score, treat this as unmaintained-by-community glue: no expectation of prompt fixes, security patches, or version bumps alongside your Laravel/Nova upgrades.
• You need rich tenant lifecycle features — billing, quotas, self-serve signup, domain/subdomain automation with deep customization. The package gives you CRUD, not a platform; you'll be extending it substantially.
• You need vendor SLAs or commercial support.

How to Pitch It (Stakeholders)

One-line summary: A small, free add-on that gives us an admin panel for managing tenants — valuable only if we've already chosen the hyn/multi-tenant engine and Nova as our admin stack.

To executives: This can compress the "we need an internal tenant management screen" workstream from weeks to days, at the cost of a Nova license we may already pay for. The strategic caveat is dependency risk: the underlying tenancy package is a niche, low-community project, so this is a tactical accelerator, not a strategic foundation. Approve it only as part of a deliberate tenancy-engine decision, not as a standalone bet.

To engineering: Treat it as thin glue over hyn/multi-tenant and Nova. Expect to own it — fork, pin, and audit before relying on it in production; no meaningful community support. If we're greenfield, the stronger recommendation is stancl/tenancy plus a modern admin layer (e.g., Filament) rather than committing to the hyn stack for the sake of this toolkit.

Recommendation: Conditional adopt — proceed only if hyn/multi-tenant + Nova is already the decided stack and the requirement is internal-only tenant CRUD. Otherwise, flag as a "do not build the platform on this" and revisit architecture first.