Vendra User Laravel Package

Product Decisions This Supports

• Build vs. buy on identity and accounts. User persistence, auth wiring, profiles, and addresses are table stakes — they don't differentiate the product. Adopting a package here converts undifferentiated engineering into roadmap capacity for what customers actually pay for. This is the "buy" side of that decision, with an MIT license as the escape hatch.
• Roadmap de-scoping. The module already ships profile handling, address management, auth integration, and Filament admin UI. Those items can leave the near-term roadmap and be treated as inherited capability; PMs should re-baseline estimates rather than re-plan the work.
• Back-office and support tooling. Filament classes for the user domain live inside the module, so operational tooling (support agents editing accounts and addresses) arrives with the feature instead of as a separate epic. That changes both the delivery date and the ongoing support-cost assumption.
• Tenancy as a retrofit, not a rewrite. Tenant-aware tables are registered with TenantTableRegistry so vendra-tenant:enable can retrofit schemas migrated before tenancy existed. This supports a product sequence of "ship single-tenant, enable multi-tenancy later" without repricing the whole user domain.
• Market and localization decisions. Translatable persistence is an explicit domain choice: each field is either translatable (JSON column, locale-aware validation, Filament locale UI, translated serialization) or scalar — never both. "Which user-facing fields must be localized for market X" becomes a priced product decision, not an engineering surprise.
• Bundling decisions. Social login deliberately lives in misaf/vendra-socialite, and tag support is negotiated through Misaf\VendraSupport\Capabilities\HasOptionalTags rather than a hard Tagger dependency. "Social sign-in" and "tagging" can be scoped and priced as separate capabilities instead of an all-or-nothing identity suite.
• Platform vs. product investment. The package is a read-only subtree split of the Vendra monorepo. Anything the product needs changed must be contributed upstream or forked, which makes "do we invest in the platform" a recurring planning line item rather than an ad-hoc request.
• Exit planning. MIT license plus a clean module boundary keeps a fork technically available; that option value belongs in any long-term dependency decision.

When to Consider This Package

Adopt when most of the following hold:

• You are building on Vendra (or a comparable modular Laravel monolith) and intend to depend on the wider package graph. The module is version-aligned with sibling packages via self.version, so partial adoption is the expensive path.
• You need a conventional Laravel user domain — Eloquent models, auth provider integration, profiles, addresses — and would otherwise rebuild it.
• You want the admin/back-office side (Filament) included from day one rather than bolted on later.
• Multi-tenancy is on the roadmap even if not in v1: the tenant-column registration makes the later switch materially cheaper.
• Localized user-facing fields are plausible for your markets, and you want the translatable-versus-scalar decision enforced at the model level instead of re-litigated per feature.
• You can accept a single-maintainer, low-visibility dependency for a non-differentiating domain, and you have a real upgrade cadence (version pinning, diff review, staging validation) rather than a set-and-forget posture.

Look elsewhere when:

• The product is a simple single-tenant app. Laravel Fortify/Jetstream/Breeze plus a hand-rolled profile has a smaller blast radius and far better documented releases.
• You need enterprise identity: SSO/OIDC/SAML, SCIM provisioning, passkeys/passwordless, MFA policy management. This is an account/storefront layer, not an IdP integration — verify parity before assuming it.
• You only want social login. That is a separate package; adopting this one to get it is a bad trade.
• You need a documented public library. One star, release notes that reduce to a compare link, and no itemized changelog mean you are buying code, not support.
• You cannot accept the Misaf\VendraSupport transitive contract. The Vendra transitive API policy treats intentionally exposed platform dependencies as part of the public contract — removing or replacing one is a breaking change, so this coupling is real.
• Your team needs to modify the user domain continuously and cannot contribute upstream (the split is read-only), making a maintained fork the only honest option.

How to Pitch It (Stakeholders)

For executives: Accounts, profiles, and addresses are required by every product in this category and differentiate none of them. This package supplies that layer — plus the admin screens support will need — under an MIT license, so engineering time goes to what customers choose us for. The trade is a concentrated dependency: a small, single-maintainer module whose releases are thinly documented. What I am asking for is a small permanent upgrade-and-review cadence rather than a one-time integration cost, plus an explicit upstream-contribution path. The license and the module boundary keep a fork on the table if upstream ever stalls.

For engineering leads:

• It follows Laravel conventions end to end: service provider, publishable config and migrations, contracts and traits for the User model, a package service for user creation, and events for onboarding/CRM hooks. Extension is via config, listeners, and separate migrations — never vendor edits.
• Boundary discipline is explicit: namespace Misaf\VendraUser, domain code stays in the module, tag support flows through HasOptionalTags, social login stays out. That keeps the integration surface small and the upgrade diff readable.
• It ships with a working agent-assisted development workflow (package-scoped Pest suite, composer stan), a genuine signal that changes are meant to be tested and reviewed — even though the changelog is not.
• Integration traps to budget for: model swap affecting password brokers and policies, migration ordering against an existing users table, duplicate routes if package routes aren't disabled, and stale config cache after upgrades.

The ask: approve adoption with three conditions — (1) pin the version and treat upgrades as scheduled work with a diff review, not a background task; (2) commit to an upstream-contribution path so product-driven changes aren't silently forked; (3) revisit the identity roadmap next planning cycle, because if SSO, passkeys, or MFA policy become customer requirements, this module is a starting point, not the answer.