Customer Laravel Package

Product Decisions This Supports

• Customer domain build vs. buy. The package ships a ready-made Customer entity (individual vs. organization), address handling, and the glue to Laravel auth/Concord users — a meaningful shortcut versus hand-rolling the same tables, models, and relationships for a CRM, SaaS, or commerce product. This directly answers the recurring "do we build our customer model from scratch?" decision early in a project.
• B2B/B2C customer modeling. The explicit distinction between natural-person and organizational customers supports product decisions around serving both consumer and business segments in one tenant — a common source of painful schema rework later.
• Architecture: modular monolith on Laravel. Because it is a Concord module, adopting it is really a bet on the Konekt/Concord modular architecture (isolated modules, migrations, config, service layer). That is a platform-level decision, not just a feature pick.
• Roadmap acceleration. For an MVP that needs customer records, addresses, and billing/shipping data quickly, this compresses weeks of foundational modeling into a dependency — provided the surrounding ecosystem is a fit.
• Scope boundary for adjacent features. It anchors customer identity and addresses, letting the roadmap defer CRM, segmentation, or lifecycle tooling until the core customer layer is stable.

When to Consider This Package

Adopt when:

• You are already committed to the Konekt/Concord ecosystem (Concord, konekt/user, konekt/address, appshell). In that context it is the natural, coherent customer module.
• You need a person/organization customer model with addresses and want a maintained domain layer rather than bespoke tables.
• You are early-stage and optimizing for speed to a working customer model, accepting ecosystem coupling in exchange.
• Your team values a single-vendor, single-maintainer modular stack and can own the upgrade surface internally.

Look elsewhere when:

• Adoption signal is the deciding factor. Seven stars and zero dependents means essentially no community validation, no battle-testing at scale, and a thin pool of people who can help. For anything production-critical, this is a strong caution.
• You are not adopting Concord. Pulling in a modular-app framework just to get customer/address models is disproportionate; the coupling cost outweighs the benefit.
• Bus factor matters. A single-maintainer package in the critical path of a revenue system is a risk to weigh against the time saved.
• Enterprise support or SLA is required — this offers neither.
• Standard Laravel approaches suffice: native models plus established packages (e.g., spatie libraries, Laravel Cashier for billing) give you more flexibility, a larger hiring pool, and easier debugging. A hand-built customers + addresses schema is small enough that "buy" only wins if the surrounding ecosystem is already chosen.

How to Pitch It (Stakeholders)

To executives: This library saves engineering time by providing a standard customer-and-address foundation — the kind of boilerplate every customer-facing product needs. The trade-off is that it is a low-adoption, single-maintainer component with no commercial support, so we should treat it as a time-to-MVP accelerant, not a long-term platform commitment. Recommend adopting it only if we are also standardizing on its parent framework (Concord); otherwise the savings are real but the dependency risk and lock-in are not justified for anything revenue-critical.

To engineering: It gives us Customer (person/org) and address models with migrations and config, integrated with Concord's module and user system. It's small, MIT-licensed, and easy to read and fork if needed. The catch is coupling to Concord and near-zero external usage — so plan to own the code path: pin versions, review the source before relying on it, and confirm the maintainer's release cadence. If we're not already in Concord, I'd lean toward a lightweight in-house model instead and revisit this if the ecosystem becomes a strategic direction.