B2B Suite Laravel Package

Product Decisions This Supports

• Build vs. buy for the entire B2B motion. The suite ships the table stakes that would otherwise be three or four separate epics: company accounts with admins and sub-users, role-based permissions, requisition lists, quick order (multi-SKU, CSV, name/SKU search), RFQ with quote-to-order, purchase orders with multi-step approvals, per-company product and category visibility, custom/quantity-tier pricing, credit limits, and Pay By Credit at checkout. The decision this unlocks: buy the undifferentiated B2B primitives and spend engineering on what actually differentiates us — pricing strategy, ERP/IdP integrations, service model, merchandising — instead of funding a from-scratch B2B program.
• Turning "B2B MVP" from a blank page into a scope conversation. Because the surface is demoable, sequencing becomes concrete: quick order + requisition lists anchor the SMB/repeat-purchase story; RFQ + tiered pricing + catalog segmentation carry mid-market; PO approvals + credit terms unlock enterprise procurement. You can cut visibly in a demo rather than argue in the abstract.
• ICP and packaging decisions. Tier/volume pricing and credit limits are not just features — they are pricing-policy and finance-risk decisions (net terms, exposure caps, dunning). The package gives you the mechanics; the policy stays ours, which is exactly where you want product control.
• Self-serve vs. assisted onboarding design. The natural first-run path — company registers → admin approves → admin creates company admin → that admin invites sub-users and assigns roles → buyer builds a requisition list and reorders via quick order — is a ready-made activation funnel. Instrument each step; it is also your first pilot script.
• Whether B2B is a channel feature or a platform feature. One answer decides a quarter of roadmap: are these capabilities exposed through Bagisto's APIs, or storefront-view only? If headless/integration buyers are in the ICP, budget integration work we own.
• Feature-flag-driven rollout as the release strategy. Nearly the whole suite reads b2b.general.settings.active, and disabling it removes routes, menus, and injected blocks cleanly. That is a per-environment, per-design-partner pilot lever — use it instead of long-lived branches.
• Owning the policy the package does not ship. Approval thresholds, spend limits, multi-level escalation, and credit review workflows are our state machine to define. This is the highest-value product surface left on the table.
• A quantified maintenance line item. Expect to consume ~30% of the suite and carry 100% of its upgrade cost. Suite majors do not track Bagisto majors, and every core upgrade (or PHP/Laravel security patch) obligates a matching suite upgrade. Put that in the roadmap per quarter, not per install.

When to Consider This Package

Strong fit when:

• You are already on Bagisto 2.5 / Laravel 13 / PHP 8.4 and can absorb a ~1-day mechanical install. If you are not on PHP 8.4, this becomes an infrastructure project wearing a feature-package costume — reassess honestly.
• You need company accounts and RBAC as the foundation, not a nice-to-have; RBAC is what unlocks every downstream buying role.
• You want 4–6 quarters of B2B scope compressed into a pilot, and you have Laravel/PHP depth in-house to read the source and extend it properly.
• You accept a small-ecosystem package (27 stars, 0 dependents, Webkul\ namespace) and are willing to be self-sufficient: read B2BSuiteManager.php, rely on the shipped E2E Playwright suite, and keep your customizations in git with a diffable published tree.
• You can adopt the extension discipline — view_render_event listeners first, subclass + container bind second, concord->registerModel for added columns (ERP IDs, IdP subject mapping) — and never patch core.

Look elsewhere (or narrow scope) when:

• You are not on Bagisto. The replatform cost dominates and a greenfield B2B build on a modern stack is a fairer comparison.
• You need deep procurement integration out of the box — cXML/OCI punch-out, ERP order sync, IdP-group-mapped permissions, spend-limit approval hierarchies. These are our build items, not the package's.
• You need a headless/API-first B2B surface with contractual guarantees. The published evidence points to storefront-view capabilities, not a documented B2B API.
• You require published performance benchmarks at 10k / 50k / 250k SKUs. Company-catalog visibility rides on a swapped core ProductRepository, so every storefront product query flows through B2B logic; there is no public evidence of behavior at volume, and a B2B defect degrades the non-B2B storefront.
• You need vendor SLAs, indemnities, accessibility certification, or a support contract. MIT means you can fork — it does not mean someone answers the phone.
• You need only one capability (say, tier pricing). Do not carry the whole upgrade surface for a slice.
• Your team lacks PHP/Laravel depth; there is no Stack Overflow corpus for this package.

How to Pitch It (Stakeholders)

To the executive team. We can stand up a credible B2B motion — company accounts, buyer roles, requisition lists, quick order, RFQ, purchase-order approvals, company catalogs, tier pricing, and pay-by-credit — without funding a from-scratch program. License cost is zero (MIT); the real cost is a standing maintenance obligation: the suite versions independently of Bagisto, so each core or PHP upgrade obligates a matching suite upgrade. Budget that per quarter and the economics stay clearly favorable. The ask is a six-week pilot on one design-partner account, behind the suite's existing config flag, with a go/no-go on conversion and operational load — not a big-bang launch.

To engineering. This is an extension-layer package, not a fork: provider registered after Shop with auto-discovery intentionally off, everything gated behind b2b.general.settings.active, behavior changed by container binding and Concord registration, UI injected via view_render_event. Follow its own patterns in our layer and upgrades stay separable in review. Two hard rules: never publish into public/themes/*/build, and never edit through vendor/. Add CI that lints/compiles views (a Vue @event colliding with a Blade directive 500s at request time while view:cache reports success). QA scope must include the anonymous and non-company shopper path on every B2B change, because the ProductRepository rebind has global blast radius.

To sales and support. The activation path is already defined and demoable: register company → approve → assign company admin → invite sub-users with roles → build a requisition list → reorder via quick order. Sell that story; it is concrete, and it exercises most of what customers actually consume. Flag drift reads as a bug — document the flag value per environment and check it first when a B2B screen 404s.

To the product org — the three questions to resolve before we commit the roadmap: (1) Is company/tier pricing a peer of core pricing or a layer above it, and how does it interact with promotions, tax, currency, and multi-store? (2) Do approval thresholds, spend limits, and credit policy ship with the package, or are they ours to build? (3) Are B2B capabilities API-exposed or storefront-only? That last answer decides whether this is a channel feature or a platform feature for us — and it is the only one that changes the shape of the roadmap rather than its sequence.