Vendra User Profile Laravel Package

Product Decisions This Supports

• Build vs. buy for "table stakes" profile plumbing. This package covers the unglamorous 80% of user profiles — profile record, avatar handling, per-field validation, update helpers, authorization hooks — plus a Filament admin UI, policy-enum permissions, and en/de/fa translations. That is typically 1–2 sprints of work a PM would otherwise have to fund before the team can touch differentiating features. The decision this informs: do we spend that sprint on profile CRUD, or on the thing customers actually pay for?
• Platform standardization, not a point purchase. This is a read-only subtree split of misaf/vendra. It ships as one module in a version-aligned package graph, so adopting it is effectively a vote for the Vendra platform. It is not a decision you can make module-by-module in isolation — that framing belongs in the roadmap review, not the backlog.
• Roadmap sequencing for identity-adjacent features. The module deliberately owns only the generic profile and a UserProfileRelationManagers extension registry; Address, Phone, Document, and Verification are separate optional packages that depend on it. That gives a PM a clean dependency map: profile → addresses (checkout/shipping) → phone (2FA/notifications) → documents/verification (KYC, payouts, regulated flows). Profile is a prerequisite gate, which is why it should land early even though it demos poorly.
• Packaging and monetization tiers. Module enablement runs through Pennant feature flags (module_enabled, features_enabled, features_discover) with global switches applied before persisted tenant values. That is a real product lever: profiles can be sold as a tier, soft-launched per tenant, or dark-launched before GA, without a redeploy.
• Admin/back-office scope decisions. The bundled resource lands in CustomersCluster immediately after Users, with policy-backed permissions per action. Product call: does support/ops get to edit customer profiles at all, and which fields? The package gives the mechanism; the policy enum is where the PM's answer gets encoded.
• Market expansion cost estimation. Shipping en, de, and fa labels as part of the contract means "add a locale" is translation work, not schema or UI work. Useful when estimating a new-market launch.
• Data-scoping decisions. Profile lives in a separate profiles table with a hasOne from User, so PII sits in a bounded, deletable place — which materially simplifies GDPR erasure, analytics exports, and "what do we hand to support?" decisions. It also constrains the product: one default profile per user, enforced by an observer plus a unique DB index. Any persona/multi-identity feature (B2B contacts, seller vs. buyer identities) is custom work, not configuration. Decide that before it appears in a sales conversation.
• Tenancy decisions. Tenant awareness is derived from the bound TenantResolver, not a config toggle, and the module builds whether or not a tenant provider is installed. Useful for the "single-tenant now, multi-tenant later" roadmap question — but note the migration path: enabling tenancy on an existing table requires an explicit artisan backfill (vendra-tenant:enable), i.e. a scheduled ops step, not a free flip.

When to Consider This Package

Consider it when:

• You have already committed (or are seriously evaluating) the Vendra platform. This is the only context in which the package's opinions are assets rather than friction.
• You need a Filament-based admin panel and don't want to hand-roll profile resources, relation managers, permissions, and translations.
• You are multi-tenant, or expect to be, and want tenancy handled centrally in a support layer rather than re-implemented per model.
• Your near-term roadmap includes addresses, phone numbers, documents, or verification — you'd be buying into the registry pattern designed to compose those without reverse dependencies.
• Your team is on current Laravel + Filament v5 and accepts lockstep upgrades across the package graph.
• You are a small team where back-office CRUD is a genuine capacity drain.

Look elsewhere when:

• You are not on Vendra. The namespace, service-provider relation registration, TenantResolver coupling, and Filament v5 conventions make this a poor fit for a general Laravel app; a plain hasOne profile model plus a form request is a day of work and zero lock-in.
• You need multiple profiles/personas per user, profile versioning, or field-level audit history as first-class features. One default profile is baked in; audit is left to observers and events you write.
• You need community support, an SLA, CVE tracking, or a broad hiring pool. One star and a read-only mirror mean the maintenance surface is a single vendor and the docs of record live in the monorepo's skill files, not in this repo.
• You need to patch vendor code. The repo is explicitly [READ ONLY] — fixes must go upstream to misaf/vendra and wait for a release. Any local fork is a permanent divergence cost.
• Release-note transparency matters to your change process. v1.12.3's notes consist of a link to a diff against v1.11.0 — a gap of two minor versions in the compare link. Upgrades require running the full suite and auditing migrations/config diffs yourself.
• You need headless/API-only with no Filament. You'd be carrying an admin UI dependency for nothing.
• The app is genuinely single-tenant and simple — the tenancy, feature-flag, and permission layers are pure overhead.

Diligence the PM should insist on before signing: pin the version, add a regression suite over profile read/write and the default-profile invariant, confirm upgrade ownership (who runs composer update across the graph and re-tests), and get the vendor to state their versioning and deprecation policy in writing.

How to Pitch It (Stakeholders)

To executives: This is not a library purchase; it's a module inside a platform decision. On its own it is unremarkable — 1 GitHub star, a read-only mirror, release notes that are a diff link. Its value is entirely contextual: if we standardize on Vendra, user profiles, admin screens, granular permissions, three locales, and multi-tenant scoping arrive already built and tested, and we redirect one to two sprints to revenue work. The risk we are accepting is single-vendor concentration and lockstep upgrades — manageable, but it should be priced into the platform decision, not discovered later.

To engineering: Adopt it as a bounded domain module, not as a starting point to fork. Keep profile data in the package table; keep User about authentication. Put validation in form requests, updates in a small action class, and authorize every write with a policy — route middleware alone is not enough. Eager-load profile on any user listing to avoid the N+1 that Blade loops invite. Extend by binding a custom profile model or contributing relation managers through the registry; do not edit vendor migrations or published views. Expect strict conventions — declare(strict_types=1), final classes, PHPDoc generics, Pest coverage, Filament v5 namespaces, translation key parity across en/de/fa — and hold contributions to them. Upgrades are graph-wide: review the compare diff, run config:clear, re-run migrations, and keep published config/migrations/views in version control so overrides don't drift.

The ask: Approve a one-sprint spike against the Vendra graph on a real tenancy configuration before committing. The deliverable is not a demo — it's an answer to one question: does this platform save us more than the lock-in costs? If yes, profiles become a checkbox. If no, we build the 200-line version ourselves and keep our options.