Profiles Api Laravel Package

Product Decisions This Supports

• Build vs. buy for the Profiles API surface. This package is small enough in scope (a presentation adapter over profile data) that its main decision value is answering "do we even need to buy this?" The realistic answer: the build is a resource controller, a resource/transformer, authorization policies, pagination/filtering, and contract tests — days, not sprints. This package is best treated as a reference implementation to price that build, not a purchase.
• Whether profiles become a first-class API resource on our roadmap. Adopting or copying it forces the product question: are "profiles" a distinct resource from "users/accounts," and is that resource part of our public contract (partner integrations, embedded apps, mobile clients) or purely internal?
• API contract and versioning strategy. The "presentation adapter" pattern exists specifically to decouple external JSON shape from the domain model. That supports a roadmap commitment to backwards-compatible API versions without freezing internal models — a real customer-facing promise, not just an architecture preference.
• Ecosystem bet: Liberu module suite vs. Laravel-native. Adding this is a vote for a broader module ecosystem (auth, profiles, API conventions). A PM should decide that as a portfolio decision, not module by module — one adapter is low value; a coherent suite is where the value is.
• Use cases it maps to: self-service profile management in an admin/customer portal, partner-facing read APIs for profile data, multi-tenant SaaS where profile records are shared across apps, and marketplace/extension surfaces needing a stable profile endpoint.
• Risk and compliance scoping. Profile data is PII by default. The decision to adopt is inseparable from field-level authorization, data export/erasure (GDPR/DSAR), and audit trail requirements — which this package, at zero dependents, provides no evidence of solving.

When to Consider This Package

Consider it when all or most of these hold:

• You are already building on the Liberu module stack or Laravel with their module conventions, so the integration cost is genuinely near zero.
• You need a thin presentation layer over an existing profiles domain model and want a concrete reference for how to structure the boundary (not necessarily the shipped code).
• You are in discovery/spike mode and want to evaluate the pattern in a day rather than author a design doc.
• Your API is internal or early-stage, with no external SLA or long-lived consumer contracts attached to it.
• You can absorb the code in-house and maintain it yourself — treat it as vendored source, not a dependency.

Look elsewhere (or build in-house) when:

• License clarity is required. NOASSERTION is not an OSI-identified license. Legal cannot clear it for redistribution or commercial dependency without written clarification. For anything customer-facing or in a distribution, this is a hard stop until resolved.
• You need a support commitment, SLA, or security responsiveness — zero stars, zero dependents, zero public usage means no battle-testing, no CVE attention, no community answer when it breaks.
• PII handling is regulated. Profiles need scoped authorization, field redaction, consent, retention, and audit. Do not assume any of that is present.
• You need search, filtering, sorting, or scale beyond straightforward CRUD — a presentation adapter is not a query engine.
• You need documentation, test coverage, or upgrade guarantees you can point a team at.
• You are not on Laravel or not on the Liberu conventions it presumes.

How to Pitch It (Stakeholders)

For executives (30 seconds): "We evaluated a small open-source Laravel component for exposing profile data through our API. It's a low-maturity package — no adoption, no community, no dependents, and an unclear license — so we are not recommending it as a dependency. What we are taking from it is the architectural pattern: a clean adapter between our internal profile model and the external API contract. That lets us ship profile endpoints in days using our own code, keep the license clean, and preserve our ability to version the API without breaking partners. Net: no procurement, no vendor risk, roughly one to two days of engineering to reach the same outcome with full control."

For engineering: "The package is a presentation adapter for profile resources — the interesting part is the boundary, not the code. We'd replicate the separation (domain model → resource/transformer → controller → versioned route) inside our own module. That gives us ownership, testability, and lets us add what this package almost certainly lacks: scoped policies, field-level visibility, pagination and filter contracts, audit logging, and contract tests. Estimated effort is small; the payoff is a contract we can evolve deliberately."

The ask: approve a one-to-two-day spike to produce our own profiles API adapter modeled on this pattern, and treat liberusoftware/profiles-api as design input only — no dependency, no license exposure, no maintenance obligation.