B2B customer portal development with Laravel and Vue.js

A B2B customer portal built with Laravel and Vue.js gives your business customers one place to check their prices and stock, place and repeat orders, download invoices and documents, and manage their own users – without calling or emailing your sales team. Laravel handles the business logic, permissions, integrations and background jobs; Vue.js provides a fast, interactive interface for catalogues, order forms and account screens. The combination works well because most of the complexity in a B2B portal is not in the front end but in customer-specific rules and the connection to your ERP, and Laravel is a mature, well-documented framework for exactly that kind of backend.

What a B2B customer portal should do

A portal is not a webshop with a login. B2B buyers have different needs from consumers, and the portal must reflect how your company actually sells. A realistic first release usually covers:

• Company accounts with multiple users – buyers, approvers and an account administrator on the customer side.
• Customer-specific prices and conditions – price lists, volume tiers, discounts and payment terms taken from the ERP.
• Catalogue with real availability – stock shown as available quantity, delivery times, packaging units and minimum order quantities.
• Fast ordering – quick order by SKU, CSV or spreadsheet upload, reorder from history, saved lists.
• Order tracking – status from the ERP, delivery notes, shipping information.
• Documents – invoices, credit notes, certificates, data sheets and other product documents per order or product.
• Self-service account management – delivery addresses, users, notification preferences.

Later phases often add approval workflows for large orders, returns and complaints, quotes requested from the portal and account-level reporting.

Why Laravel for the backend

Laravel is well suited to B2B portals for practical reasons rather than fashion:

• Authorisation built in. Policies and gates make it straightforward to express rules such as "a buyer can place orders up to their limit, an approver can release larger ones".
• Queues and scheduling. Laravel queues with Redis, monitored through Horizon, handle ERP synchronisation, document generation and notifications in the background. The scheduler runs nightly reconciliations.
• API-first development. The same backend can serve the Vue.js interface, a mobile app or partner integrations, with token authentication through Sanctum.
• Mature ecosystem. Search (Scout with Meilisearch or Typesense), file storage, mail, testing and localisation are covered by first-party or well-maintained packages.
• Long-term maintainability. Current Laravel releases run on modern PHP (8.3 and newer), follow a predictable release cycle and are familiar to a large pool of developers – which matters when you plan to run the portal for years.

Vue.js on the front end: two ways to build it

There are two common architectures, and the choice depends on your team and your requirements.

Inertia.js with Vue 3

Laravel handles routing and controllers, while pages are Vue 3 components rendered through Inertia. There is no separate REST API to maintain for the portal itself, authentication uses standard Laravel sessions, and a small team can move quickly. This is our default for portals where the web interface is the main client.

Separate SPA consuming an API

The Vue 3 application is a standalone front end talking to a Laravel API. This adds work – API versioning, token handling, CORS – but makes sense if the same API will serve a mobile app or external partners, or if front-end and backend teams work independently.

In both cases we use the Composition API, TypeScript and Vite. For data-heavy screens such as order history with filters or large price lists, techniques like server-side pagination, virtualised tables and debounced search keep the interface responsive. We describe these in more detail in Vue.js front-end development for data-heavy admin panels.

The ERP connection decides the project

Almost every portal depends on an ERP for prices, stock, customers, orders and invoices. The integration should be designed as a separate layer, not scattered through controllers:

1. Master data (products, customers, price lists) flows from the ERP into the portal database on a schedule and on change events.
2. Prices are either calculated in the portal from synchronised rules or delivered by the ERP as ready-made customer price lists – whichever reproduces the ERP result reliably.
3. Orders are written to a queue and sent to the ERP with the portal order ID as an idempotency key, so retries never create duplicates.
4. Statuses and documents return from the ERP and are shown in the customer's account.
5. A nightly reconciliation compares stock and open orders to catch drift.

If the ERP is offline, customers can still browse and order; orders wait in the queue. We cover the integration layer in API integration services for ERP, CRM and ecommerce.

Security and access control

• Every query is scoped to the customer's company, enforced centrally rather than in individual controllers.
• Roles and limits (who can order, approve, see prices or invoices) are configurable per customer.
• Invitations and password resets are handled by the portal; single sign-on can be added for large customers.
• Sensitive actions – changing addresses, adding users – are logged with the user and time.
• Documents are served through signed, expiring URLs rather than public file links.

Common mistakes

• Building a consumer shop and adding a login. B2B needs company accounts, conditions and document access from day one.
• Price logic that differs from the ERP. If the cart shows one amount and the invoice another, trust in the portal disappears quickly. Test prices for a sample of customers and products before launch.
• Ignoring packaging units. Ordering "1 box" must reach the ERP as the correct number of base units.
• Launching to all customers at once. A pilot group of friendly customers finds usability problems cheaply.
• No one owning the portal internally. Someone on the sales or customer service side needs to manage accounts, content and feedback.

A phased plan

1. Discovery – customer segments, pricing rules, ERP capabilities, required documents.
2. Read-only portal – catalogue, prices, stock, order history and invoices. Customers still order the old way, and you verify data quality.
3. Ordering – cart, quick order and reorder, orders sent to the ERP, first with manual confirmation.
4. Self-service – user management, addresses, returns.
5. Extensions – approvals, quotes, reporting, additional languages.

Our work for Inspirion GmbH, a B2B and e-commerce project with API integration, followed a similar logic of connecting the customer-facing platform to existing back-office data.

Next step

List your three most common customer requests that currently go through email or phone – for example "what is my price", "where is my order" or "send me the invoice again". Those requests define the first release of the portal. You can read more about our approach on the B2B customer portal page or contact us to talk through your pricing rules and ERP setup.