Framework Laravel Package

Product Decisions This Supports

• Build vs. buy for the commerce core. Vanilo gives you the commodity 80% of commerce domain logic — products and variants, pricing, carts, checkout flow, orders, payment and shipping method abstraction, tax calculation, channels, properties/attributes — as MIT-licensed PHP you own. The decision it really informs is not "build or buy a store" but "which layer do we pay someone else for": the domain engine (this), the admin/merchandising UI (build, or layer Nova/Filament on top), and the storefront (build).
• Feature roadmap sequencing. Because the domain model already exists, roadmap items like customer-specific price lists, multi-channel catalogs, configurable/bundled products, partial fulfillment, or quote-to-order become "extend the model" rather than "greenfield schema design." It shifts the first two quarters of commerce work from plumbing to differentiation.
• Pricing and packaging decisions. Native support for channels, price lists, and tax categories makes it cheap to test B2B tier pricing, regional catalogs, or net-vs-list pricing without a re-platform. It also makes "can we support this segment?" a config/extension question rather than a vendor-negotiation question.
• Data ownership and integration strategy. Commerce data lives in your database, in your Laravel app, next to your existing customer master, ERP sync, and warehouse logic. That collapses the "which system is the source of truth" debate that dominates SaaS commerce integrations.
• Vendor concentration and exit risk. MIT + self-hosted means no platform rent, no transaction take rate, and no forced migration. It also means you own uptime, security patching, PCI scope, and the upgrade treadmill — a decision the roadmap must budget for.
• Best-fit use cases to evaluate against: B2B/wholesale portals with contract pricing and quotes; catalogs with heavy configurability (units of measure, properties, variants); commerce embedded in an existing Laravel product; internal order-entry and back-office tooling; regional/multi-channel storefronts where the UI is bespoke anyway.
• Poor fit for decisions where the storefront is the product and time-to-first-order in days matters more than code ownership.

When to Consider This Package

Consider it when:

• You have an in-house Laravel team already shipping to production — PHP 8.x, Eloquent, queues, service container fluency is assumed, not aspirational.
• Commerce is a differentiator or your catalog/pricing logic is genuinely unusual (customer-specific contracts, tiered/B2B pricing, multi-channel, complex variant and property matrices). This is where SaaS platforms force you into workarounds.
• You need the data in your own schema — ERP integration, existing customer master, compliance/retention constraints, or analytics that can't live in someone else's warehouse.
• You already have (or will build) the admin and storefront layers, or you have an internal back-office that just needs a commerce engine behind an API.
• You can absorb a 6–12 week path to a credible first order, versus roughly days on a hosted platform.
• You're comfortable with a smaller ecosystem: fewer plug-and-play connectors, more direct API integrations, and diligence on maintenance depth.

Look elsewhere when:

• Non-technical merchandisers must run the catalog on day one. Vanilo is a framework, not an admin product; you supply the UI.
• You need a large app/connector marketplace — tax, ERP, PIM, and marketing integrations are yours to build.
• Checkout reliability, uptime SLAs, and PCI compliance need to be someone else's contractual problem — a hosted platform or a commercially supported distribution is the honest answer.
• You're building a multi-vendor marketplace at scale, or a high-volume B2C store where battle-tested checkout conversion is the core metric.
• Your team lacks Laravel depth, or hiring PHP/Laravel engineers is harder for you than hiring for a hosted platform's ecosystem.
• Project timeline is measured in weeks, not quarters.

Diligence before committing: confirm which capabilities sit in the MIT core versus commercially licensed add-ons (admin, advanced modules) so the true cost of ownership is priced in; verify maintainer depth and release cadence directly rather than trusting registry metadata — the listed release date and a dependent count of zero are almost certainly artifacts of how this package is distributed (consumers typically pull the meta-package or individual modules), but they should be checked, not assumed; and skim the issue tracker for responsiveness on payment/shipping edge cases.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: This is an MIT-licensed commerce engine for our existing Laravel stack. We would own the code and the data, pay no per-transaction fee and no platform subscription, and be able to shape pricing, catalog, and checkout logic around how we actually sell rather than around a vendor's roadmap. The trade is explicit: we move spend from subscription line items to engineering hours, and we take on hosting, security, and upgrade responsibility. It pays off where order volume is meaningful, where our commerce requirements are non-standard, or where owning the customer and order data is strategically important. It does not pay off if we need a merchandising UI and a live store in weeks. Recommendation: fund a time-boxed 3–4 week spike, scope one real catalog and one real checkout path, and set a go/no-go gate against a hosted-platform quote before committing to the roadmap.

For engineering — what you're actually adopting: A domain layer, not a storefront and not an admin panel. Expect Concord-style modular packages (contracts with Eloquent implementations) covering catalog, pricing, cart, checkout, orders, payment and shipping abstractions, and tax — wired into standard Laravel conventions with no black-box runtime. Most components are swappable via the container, which is the main architectural upside: we can replace pricing or tax logic without forking. The cost is real integration work — payment and shipping providers, admin surfaces, and checkout UX are ours to build and test. The payoff is a commerce model we can unit-test, extend, and reason about, sitting next to the rest of our application instead of behind an API boundary.

Framing the risk honestly: the open questions are ecosystem size and maintainer concentration, not code quality. Present it as "buy the domain, build the experience" — and validate the maintenance and licensing picture during the spike, before it becomes a roadmap dependency.