B2B Suite Laravel Package

Technical Evaluation

Architecture fit. This is a Bagisto extension, not a standalone Laravel package — its value is entirely contingent on already running Bagisto 2.5. It extends core through the sanctioned mechanisms rather than forking: B2BSuiteManager.php does $app->bind(CoreClass::class, B2BClass::class) and concord->registerModel(...), while EventServiceProvider injects UI through view_render_event(...) + addTemplate('b2b::...'). That is the right shape for upgrade survivability and it means our customization layer can sit alongside it using the same three patterns (listeners, subclass+bind, Concord registration) without touching core. The cost of that design is blast radius: the company catalog swaps the core ProductRepository, so every product query in the storefront flows through B2B logic, including for anonymous and non-company shoppers.

Integration feasibility. The gating item is the version window, not the feature set:

If the estate is not on PHP 8.4, this is an infrastructure program wearing a feature-package costume. If it is on Bagisto 2.5, the mechanical install is roughly a day: composer require, register the provider in bootstrap/providers.php after Shop (auto-discovery is intentionally disabled and must stay that way — discovery loads the provider too early and breaks the package), then php artisan b2b-suite:install. Prebuilt Tailwind bundles ship with it, so no npm run build is needed for a stock install.

Technical risk. Ranked by what would actually derail a launch:

1. Global product-query impact. A B2B defect degrades the non-B2B storefront. QA and on-call scope must include non-B2B traffic; do not triage incidents as "B2B only."
2. Silent publish overwrites. Everything lands in resources/views/vendor/<namespace>, so install-time republishing over our existing overrides is file-level and silent — last publish wins. Whether b2b-suite:install has an idempotent upgrade path is the single most important unknown before we customize a single blade.
3. Bus factor. 27 stars, 0 dependents, Webkul\ maintainer namespace. There is no Stack Overflow corpus; troubleshooting is read-the-source. Commercial support from the vendor is the realistic mitigation and should be priced into the business case.
4. Version lockstep. Suite majors do not track Bagisto majors, and a Laravel or PHP security patch can force a suite upgrade ahead of maintainer readiness.
5. Late-failing defects. Vue @event names colliding with Blade directives produce broken PHP that 500s at request time while php artisan view:cache reports success. Mitigable with a CI view-lint step and browser rendering of B2B screens.

Key questions to resolve early, because each one changes the design:

• Is company/custom/tier pricing a peer of core pricing or a layer above it — and how does it interact with promotions, tax, currency, and multi-store? The docs do not evidence this.
• Do purchase orders and RFQ ship multi-level approval thresholds and spend limits, or do we own that policy? The package appears to expose mechanics, not thresholds — treat approval as a state machine whose rules are ours.
• Does RBAC cover admin scope or storefront only, and can permissions map to IdP groups?
• Are B2B capabilities exposed through Bagisto's APIs, or storefront-view only? That single answer decides whether B2B is a channel feature or a platform feature for us.

Integration Approach

Stack fit. Greenfield-on-Bagisto-2.5 is the clean path. An existing Bagisto 2.4 estate means suite 2.0 on the maintenance branch, which is a deliberate trade of feature currency for stability. Anything not already on Bagisto is out of scope for a package evaluation and should be re-baselined as a platform decision.

Migration path. Buy the undifferentiated primitives (company accounts, sub-users, RBAC, requisition lists, quick order, RFQ, purchase orders, catalogs, tier pricing, credit limits) and spend engineering on what differentiates us — pricing logic, ERP/IdP integrations, service model. The realistic planning assumption is that we consume roughly 30% of the surface and carry 100% of the upgrade cost, so the roadmap line item is "upgrade review across the full published surface," not "upgrade the modules we use."

Compatibility and pinning. In a development checkout the package lives at available-extensions/bagisto/b2b-ecommerce and is symlinked into vendor/ by a path repository; it declares no "version", so our app must pin one via the repository entry's options.versions because Bagisto's root sets minimum-stability: stable. Never edit through vendor/ — writes reach the clone but stay invisible to its git status. Our own overrides belong in our repo with a README naming every published file we have touched, plus a post-upgrade diff of the published tree against the package's publishables/.

Sequencing. Use the config flag b2b.general.settings.active as the rollout lever rather than a branch.

1. Stand up the flag off and confirm the storefront and admin render cleanly with no B2B affordances.
2. Install and run the first end-to-end use case on a production-like snapshot: company registration → admin approves company → admin creates/assigns a company admin → that admin invites sub-users and assigns roles → a buyer builds a requisition list and reorders via quick order. That one path exercises company management, RBAC, requisition lists, quick order, and the flag.
3. Flip the flag off again and verify clean degradation.
4. Gate any custom B2B behavior behind the same flag, then pilot with one or two design-partner accounts per environment.
5. Only then layer on RFQ → quote → order, purchase order → approval → order, credit checkout, and tier pricing — probing promotion/tax/currency/multi-store interactions before any of them is sold internally.

Rollout control. Prefer view_render_event listeners for new UI, subclass+bind for behavior (documenting every bind, since each is a global change), Concord registration for added columns such as ERP IDs or IdP subject mapping, and namespaced view overrides only where we are genuinely restyling. Never build or publish into public/themes/{admin,shop}/default/build — core upgrades revert that silently — and never reorder the package's asset injection at head.before, which is deliberate and whose disturbance previously broke the admin sidebar and toasts.

Operational Impact

Maintenance. Version lockstep is a standing quarterly cost, not a per-install one. Every core upgrade obligates a matching suite upgrade, and a PHP or Laravel security patch can pull a suite upgrade forward ahead of maintainer readiness. Plan a recurring review of the published view tree and of every container bind we own.

Support. With 27 stars and zero dependents there is no community corpus; the ramp-up path is reading the source in a fixed order — Providers/B2BSuiteManager.php first (it is the whole architecture in one file), then Providers/EventServiceProvider.php, then publishables/ — and checking the flag value before debugging anything. A commercial support arrangement with the vendor is the sensible hedge and belongs in the TCO.

Scaling. Company-catalog visibility rides on the swapped ProductRepository, so every product query in the storefront is affected. There is no published evidence for behavior at 10k / 50k / 250k SKUs. Load-test with a realistic company catalog, and budget for query-shape and caching work before wide rollout.

Failure modes to instrument for:

• Flag drift across environments presenting as "missing routes and menus" — record the flag value in environment documentation and check it first when a B2B screen 404s.
• Silent view-publish overwrite on upgrade — diff the published tree every time.
• Invalid compiled views passing view:cache — add a CI step that lints/compiles views and, ideally, renders B2B screens in a browser.
• Non-B2B storefront degradation from a B2B-side defect — keep non-B2B paths in the regression suite.
• Custom theme tokens missing from the package bundle — deliver and verify them separately against the built manifest.

Ramp-up. Credit the package for adding an end-to-end Playwright suite in v3.0.1 covering registration, quotations, purchase orders, Pay By Credit, users and roles, catalogs, requisition lists, quick order, and company profile, run in CI on MySQL, MariaDB and PostgreSQL — that is our regression baseline and materially lowers the cost of first adoption. Two behaviors from that release are worth encoding as our own rules: catalog membership is enforced at write time (out-of-catalog items stay behind with a notice and cannot be added to a list), so any extension to list mutation must not open a second, unvalidated path; and the quick order search regression means that if we customize product search we must exercise all three inputs — multi-SKU box, CSV upload, and search-by-name/SKU — not just the one we touched.