Contracts Laravel Package

Product Decisions This Supports

• Buy vs. build for the commerce backbone. The contracts define the domain vocabulary — products, orders, customers, carts, payments, shipping, tax, promotions — that a Laravel commerce stack must speak. If your roadmap includes e-commerce, this package is the schema-level decision point: do you adopt an existing contract set (Vanilo) or define your own domain model?
• Extensibility strategy. Because the package is interface-only, it lets you implement custom product catalogs, order workflows, or payment adapters that still interoperate with the rest of the ecosystem. This directly informs the "build custom modules vs. configure off-the-shelf" trade-off in your platform roadmap.
• Vendor lock-in and portability. Contracts are the seam that separates your business logic from any single vendor's implementation. Adopting (or mirroring) these interfaces is a hedge against re-platforming costs if you later swap payment, shipping, or fulfillment providers.
• Team topology and parallelization. Interface-first design is a staffing decision as much as an architecture one. It lets separate teams build against stable boundaries — one team on checkout, another on catalog — without constant coordination. Worth weighing when you plan squad structure for a commerce build.
• Integration and partner evaluation. Third-party commerce services and internal modules can be assessed against "does it conform to our contracts?" That becomes a concrete, PM-legible acceptance criterion for vendor RFPs and integration scoping.
• Roadmap sequencing for commerce features. The contract surface maps cleanly to capability areas (catalog, checkout, payments, fulfillment). Use it as a checklist to decide which commerce capabilities are in-scope for a given release and which stay stubbed behind an interface.

When to Consider This Package

• You are already on, or seriously evaluating, Vanilo. The contracts are a transitive dependency of the framework. Adopting them standalone has no value — they are only useful when paired with implementations that satisfy them.
• You need a composable, headless-style commerce foundation on Laravel/PHP. If your stack is Laravel and you want domain interfaces you can implement and swap, this is a reasonable, MIT-licensed vocabulary to build against.
• You plan to build custom commerce modules. If your product strategy is "own the differentiators, buy the commodity," the contracts give you a stable boundary to write proprietary modules against.
• Look elsewhere if: you are not on Laravel (the ecosystem is Laravel-centric and the contracts assume Eloquent-shaped models); you need a standalone commerce library rather than part of a framework; you require a large, well-funded ecosystem with active community support — 3 stars and effectively zero visible dependents signal a small-maintainer project, so treat it as infrastructure you inherit, not a product bet; or you need commerce primitives beyond what Vanilo covers (e.g., advanced multi-tenant marketplace logic, or non-PHP services).
• Watch the version-coupling risk. Contracts tend to bump major versions in lockstep with the framework. If you fork or implement them directly, budget for maintenance across upgrades. For most teams the correct posture is: consume them indirectly through Vanilo rather than depending on this repo in isolation.

How to Pitch It (Stakeholders)

To executives: This is not a product — it is the "rulebook" that defines how a Laravel-based commerce stack describes products, orders, and payments. Its strategic value is low-cost lock-in protection: because it is MIT-licensed and interface-only, swapping vendors or building custom modules later does not require rewriting core business logic. The trade-off is ecosystem maturity — this is a small community project, so we should treat it as plumbing we can afford to own or replace, not a strategic platform bet. Recommended posture: adopt only if we are committing to Vanilo, and scope a spike to validate the fit before we build on it.

To engineering: The contracts package is the clean boundary you want. Interfaces only, MIT, no runtime coupling — implement the parts of the domain you need (product, order, checkout, payment) and leave the rest stubbed. It gives us parallelism across teams, a defensible abstraction for swapping payment/shipping providers, and a natural place to enforce conventions. The risk to flag: low stars, minimal visible dependents, and version bumps likely tied to Vanilo majors. Plan for a thin internal adapter layer so a future upgrade — or exit — is a contained change rather than a rewrite.