Ladmin Laravel Package

Product Decisions This Supports

• Identity architecture: one user table or two? Version 2.1.0 makes the package's opinion explicit — admins get their own guard, their own ladmin_accounts table, their own Modules\Ladmin\Models\Admin model, and their own factory/seeder. This is a real product decision, not a technical detail: separate identities mean separate session lifetimes, password policies, MFA rollout, lockout rules, and audit scoping for back-office staff versus end customers.
• Build vs. buy for the admin surface. A one-command install (--with-admin-table) that produces guard, migration, model, factory, and seed data is a meaningful reduction in back-office bootstrap cost. The buy decision now includes an implicit commitment to the package's admin user model.
• Roadmap unlock. Segregated admin identities make role-based access control, admin MFA, per-admin audit trails, and segregation-of-duties controls cheaper to deliver later — these become additive work on an existing guard rather than a refactor of the primary auth stack.
• Use cases served: internal operations dashboards, customer support tooling, back-office CMS, admin-only APIs, and any product where "who can administer this" must be answerable separately from "who is a customer."
• Scope boundary to set now: this release does not solve admin provisioning, invitation flows, admin lifecycle/deprovisioning, or SSO. Those remain product decisions you own.

When to Consider This Package

Consider it when:

• You are greenfield or early enough that adopting an opinionated admin guard and ladmin_accounts table is cheap.
• You genuinely want admins decoupled from customer accounts — separate credentials, separate login surface, separate blast radius.
• You want back-office scaffolding in days, not sprints, and are comfortable with a modular (Laravel Modules) code layout.
• You can absorb the installer's side effects on a clean branch and review the diff.

Look elsewhere — or adopt with explicit mitigations — when:

• You already have a multi-guard auth configuration. This release overwrites config/auth.php to inject the admin guard; that is a destructive, non-mergeable write. Treat the install as a migration requiring a reviewed diff and version control, not a fire-and-forget command.
• DatabaseSeeder is overwritten and a new AdminFactory is introduced. Seeded admin credentials and factory-generated accounts are a development convenience and a production liability — plan real provisioning before any deployed environment.
• You require enterprise SSO/SAML/OIDC for admins, or admins must be the same principals as existing users.
• You need a mature, heavily-audited admin framework (Filament, Nova, Backpack) with a broader ecosystem and long-term support story.
• Your compliance posture demands segregation-of-duties evidence; a package-managed admin table is a starting point, not a control.

Net read: 2.1.0 is additive, not breaking, but it is opinionated and invasive at install time. The risk is not upgrading — it is running the installer against an established codebase.

How to Pitch It (Stakeholders)

To executives: This release lets us stand up a separate, properly isolated back-office admin system in a single install step instead of building one. The business value is speed to market for internal tooling plus a cleaner security boundary — admin access is its own door, not a flag on a customer account, which makes future access controls and audit requirements cheaper to meet. Cost is low; the main caution is that the installer modifies existing configuration and seed files, so we should run it once, deliberately, on a clean branch.

To engineering: Treat 2.1.0 as a scaffolding generator, not a dependency to consume passively. It adds an admin guard by rewriting config/auth.php, ships a migration for ladmin_accounts, introduces Modules\Ladmin\Models\Admin as the default admin principal, and overwrites DatabaseSeeder while adding AdminFactory. Run the installer in isolation, diff every overwritten file before committing, pin the version, and decide up front how production admin accounts are created, rotated, and revoked — never via the shipped seeder or factory. If we already run multiple guards, budget time to reconcile this config rather than accept the overwrite.