Partner Laravel Package

Product Decisions This Supports

• Build vs. buy for the counterparty data model. The package ships Eloquent models, migrations, polymorphic relationships, and configurable partner types/statuses for partners, contacts, and addresses. For a PM, that is a candidate shortcut of roughly two to six weeks of schema and CRUD work — but only if the host application's user/tenant model aligns with MyBizNa's assumptions.
• Roadmap sequencing of a "partner registry" as a foundational entity. Customer, supplier, and contact records are referenced by billing, procurement, CRM, marketplace, and reporting features. Deciding whether that registry is adopted, built, or bridged determines the shape of every downstream feature and should be settled before those features are scoped.
• Feature scope for an MVP. A partner registry, contact directory, address book, and partner-type taxonomy are classic "table stakes, not differentiation" features. Adopting rather than building lets a small team spend its roadmap budget on differentiators.
• Data-model lock-in as a product decision, not just a technical one. Partner records are a core entity; the schema chosen now constrains deduplication, reporting, segmentation, and future sync with any CRM or ERP system of record. This is the highest-reversal-cost decision in the evaluation and belongs on the product risk register, not only in engineering's backlog.
• Dependency governance and release-process risk tolerance. Zero stars, zero dependents, a single maintainer, one release note that is only a compare link, and a version tag (2025.001) that sorts below the prior tag (2025.2) under Composer's normalisation. The score of 0.36 reflects package maturity; the opportunity score of 6.59 reflects the value of the problem space. That gap is the actual decision: is the domain valuable enough to accept an immature delivery vehicle?
• Pilot framing for internal tools. Suitable decision context: prototypes, internal admin surfaces, back-office registries behind a feature flag — where time-to-learn matters more than long-term support.
• Explicitly not supported: procurement decisions requiring an SLA or security-disclosure process, strategic platform commitments, or any scope where the partner record is a regulated system of record.

When to Consider This Package

Consider it when:

• The host app is a Laravel project that already consumes MyBizNa modules (or an equivalent shared core for users, tenants, and settings), so integration is largely wiring and config.
• You need exactly this shape — partners plus contacts plus addresses, polymorphic attachment to any entity, configurable types and statuses — rather than a broad CRM.
• You are time-boxing a pilot or internal tool and can pin an exact version and commit the lockfile.
• You have at least one engineer fluent in Laravel package conventions (1–2 days ramp) plus capacity to read the release diff as the changelog.
• You are willing to own an internal integration note, and potentially a fork, if upstream stalls.
• Your acceptance gate is empirical: version intent confirmed, migrations verified reversible, no in-place migration edits, and the next release ships human-readable notes.

Look elsewhere when:

• Partner or customer records will be a system of record with billing, regulatory, or financial-reporting obligations — the schema risk is too high to inherit.
• You require an SLA, LTS signal, security advisories, or a documented support policy. None are evidenced here.
• You need PostgreSQL/SQLite portability or a non-standard auth/tenancy schema; the package likely bakes in MyBizNa conventions, and adapting around that can cost more than building.
• You already run a CRM or ERP (HubSpot, Salesforce, Odoo, Stripe Customers). A sync bridge or adapter to the existing system of record is the cheaper path.
• Composer range constraints matter to your dependency policy. Until the version-ordering anomaly is explained, only exact pins are safe — a poor fit for platforms that expect semver ranges.
• Key-person risk is unacceptable: one maintainer, zero dependents, and no changelog discipline is a leading indicator of recurring upgrade archaeology, not a one-off inconvenience.

Adoption checklist (all must be true before a build slot): supported Laravel/PHP versions stated; migrations reversible and unedited across releases; user/tenant coupling exposed via contracts rather than hard-coded; config publishable and diffable; maintainer responsive on version intent.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: mybizna/partner is a Laravel module from the MyBizNa ERP family that provides a ready-made data layer for partners — the single record of customers, suppliers, and contacts, with contacts, addresses, and configurable partner types. Partner modeling is table stakes for CRM, procurement, and marketplace features, so reuse could compress weeks of schema work into days; the 6.59 opportunity score says the problem is worth solving. The package itself, however, is unproven: 0 stars, 0 known dependents, a single maintainer, no changelog, and a release tag that sorts below the previous one, which makes safe version constraints impossible today. Overall score: 0.36. The recommendation is a bounded, feature-flagged pilot — not a production dependency.

The ask: Approve one to two weeks of engineering for a sandbox spike and data-model review, with a hard gate before production. The gate is two facts, not opinions: (1) the maintainer explains whether 2025.001 supersedes 2025.2; (2) the next release ships a human-readable changelog. Both are cheap tests of whether this project is safe to depend on.

For engineering:

• Pin exact version 2025.001, commit the lockfile, and run only on a scratch branch against a disposable database. Do not use version ranges until the ordering anomaly is resolved.
• Answer five questions first: Laravel/PHP support matrix, database portability, whether migrations were edited in place (checksum them), whether user/tenant coupling is hard or contract-based, and whether any frontend assets ship.
• Treat the compare diff as the changelog. Triage into schema, public API, config, and dependency changes.
• Deliver a one-page data-model coupling assessment against our existing entities within the week. That document is the real deliverable — it has value even if we never ship the package.

Why this framing is safe: the downside is capped at roughly two engineer-weeks and produces a validated partner/contact/address schema, an integration note, and a fork-ready copy. The upside is skipping foundational schema work on a feature every downstream module needs. Cheap to try, expensive to be wrong about — so we try small and let evidence, not enthusiasm, make the call.