B2B wholesale portals: SaaS or custom development?

Why a B2B portal is now part of the sales system

Wholesale buyers expect current availability, negotiated pricing, documents, and order status without waiting for a sales representative. At the same time, a first order, an exception, or a complex commercial decision still benefits from a knowledgeable person. A portal should therefore remove repetitive work rather than remove the sales team.

McKinsey's 2026 Global B2B Pulse reports that buyers use an average of ten channels across the purchase journey and that 71% of surveyed B2B companies offer e-commerce. Gartner reports that 61% of surveyed buyers prefer an overall rep-free experience, while still seeking seller input for tasks that require company-specific judgment. The design implication is clear: make recurring transactions self-service and reserve human expertise for decisions where context changes the outcome.

What a wholesale portal should actually automate

Start with the complete order journey, not a screen inventory. A buyer finds an item, sees account-specific terms, assembles and approves an order, chooses delivery, receives an invoice, follows payment and fulfillment, downloads documents, raises a claim, or repeats a previous purchase. On the supplier side, the order may need credit checks, inventory reservation, ERP processing, and status updates back to the portal.

A storefront is not automation if a representative must retype every order into the ERP. Automation begins when every data object has an owner, updates travel reliably in both directions, and integration failures are visible and recoverable.

• account-specific catalogs, search, substitutes, and availability;
• contract pricing, discounts, credit limits, and pack-size rules;
• quick reorder, bulk order entry, and saved baskets;
• approvals, reservation, payment, delivery, documents, and status;
• claims, returns, service requests, and interaction history;
• order analytics and signals that tell a representative when human help is valuable.

When a SaaS B2B portal is the better choice

SaaS provides a maintained product through a subscription. The vendor operates the platform, releases updates, and usually supplies standard integrations. It is a strong choice when a company wants to validate a digital channel quickly and its workflow resembles the common catalog–account price–order–status–document pattern.

Fast delivery still requires discovery. Test the product against real account structures, legal entities, buyer roles, contracts, units, case quantities, warehouses, and pricing rules. If a critical step survives only through spreadsheets and manual workarounds, a low implementation price becomes a recurring operating cost.

• the workflow is standard and is not itself a competitive advantage;
• the business needs an MVP without building a permanent product team;
• available APIs, webhooks, or ERP connectors cover the required data flow;
• the company accepts the vendor's roadmap, limits, and data model;
• SLA, export, backup, and exit terms are explicit before purchase.

When custom development is economically justified

Custom does not automatically mean better. It becomes rational when a packaged product would force the company to abandon a valuable workflow or cannot connect critical data. Typical signals include complex pricing matrices, multi-stage approvals, regulated receiving and labeling, industry calculations, multiple operational roles, proprietary analytics, or one environment that must serve both customers and employees.

A custom product gives the company control over data, experience, and sequencing of investment. It also transfers responsibility for architecture, security, observability, support, and continuous development. The budget must cover the life of the product, not just the first release.

The hybrid option: a packaged core with a custom product layer

A company can keep identity, catalog, or baseline ordering in a packaged platform while building its own integration layer, mobile experience, analytics, roles, or industry modules. This reduces the initial build surface but introduces two roadmaps and multiple support boundaries.

A hybrid approach works when the line is drawn around data and accountability. Teams must know which system owns each object, who handles a failure, how SaaS upgrades are tested, and how the custom layer survives a vendor change.

Decision matrix: SaaS, custom, or hybrid

The first-year price is not a sufficient comparison. The model affects change velocity, integration effort, service quality, and the ability to retrieve data. Use this matrix for screening, then validate the shortlist against two or three real order scenarios rather than a generic product demo.

ERP integration starts with data ownership

Integration is not a single connector. It is an agreement about the movement and ownership of each object. The ERP will often own products, inventory, base pricing, contracts, payments, and fulfillment. The portal owns the session, basket, presentation, and order capture. A CRM may own opportunities, communications, and sales tasks. Allowing three systems to edit the same status guarantees inconsistency.

1C officially supports REST/OData and site exchange mechanisms for products and orders. Technical access does not define business behavior, however. Teams still need rules for sync frequency, idempotency, duplicate handling, reservation, partial shipment, returns, and replay after failure.

• assign one source of truth to every important object;
• define direction, frequency, and acceptable sync delay;
• design conflict resolution and message replay;
• make integration history useful to support teams, not only developers;
• test an ERP outage from both the buyer and sales perspectives.

An MVP that buyers will actually adopt

The MVP should complete one operating loop. For wholesale, this is often the reorder journey: sign in, current catalog, account terms, basket, order creation, ERP confirmation, and a useful status. One complete journey produces more value than ten unfinished modules.

Use post-launch evidence to prioritize the next layer. Recommendations require trustworthy purchase history. Advanced analytics matters only when a metric leads to a decision. An AI assistant cannot compensate for inaccurate stock or a confusing approval flow.

• baseline: roles, catalog, account terms, order, status, documents, and support;
• context-dependent: multiple entities, buyer-side approval, claims, and mobile field use;
• after data quality is proven: recommendations, forecasting, advanced analytics, and AI workflows.

How a portal can affect revenue—and what to measure

A portal does not create revenue by itself. It introduces mechanisms that may improve it: reorder friction falls, the available range becomes visible, a representative can spot declining activity earlier, and relevant account offers appear at the right moment. Results depend on accurate data, a usable journey, and genuine migration into the digital channel.

Capture a baseline before development: manual-order share, handling time, corrections, repeat rate, active-account rate, order interval, and support load. After launch, registrations are a weak proxy. Measure changed behavior and process economics.

• share of orders completed through self-service;
• time from basket creation to confirmed order;
• handling cost per order;
• share of orders requiring manual correction;
• repeat-order frequency and interval;
• 30-, 60-, and 90-day account activation;
• support contacts per hundred orders.

TCO and ROI without optimistic vendor math

For SaaS, include configuration, subscription, usage tiers, integrations, support, custom work, training, and eventual migration. For custom software, include discovery, design, development, infrastructure, security, monitoring, support, roadmap work, and integration maintenance. Compare the same horizon—such as three years—so a low entry price is not measured against a complete lifecycle.

Use incremental gross profit rather than revenue. Labor savings count only when released capacity is actually removed, reassigned, or used to serve additional accounts.

SaaS security remains a shared responsibility

A SaaS vendor operates more of the stack, but the customer remains responsible for data, identities, user lifecycle, access configuration, and endpoints. Microsoft and CISA describe this as a shared-responsibility model. A certification or a recognizable provider name is not a substitute for evaluating the specific product and contract.

Request data-location and backup details, audit logs, MFA and SSO support, tenant isolation, incident-notification terms, deletion timelines, and a complete export format. Test restoration after accidental deletion and establish how the company retrieves its data when the relationship ends.

Implementation: from process diagnosis to customer migration

Map the current order before selecting software: people, systems, documents, waits, and exceptions. Choose one end-to-end journey, record baseline metrics, and test SaaS candidates with real account data. If the shortlist cannot support critical conditions, design a custom or hybrid architecture around those gaps.

Launch is not complete when the URL goes live. Use a pilot account group, train the sales team, establish feedback and integration monitoring, and migrate order volume deliberately. If representatives continue to accept every reorder through messaging apps, even an excellent portal remains an expensive catalog.

• map the current process and baseline;
• choose one complete MVP journey;
• test SaaS with real roles, prices, and orders;
• design data ownership and failure handling;
• pilot with a limited customer group;
• move volume progressively and measure real adoption.

DWG Platform: when the operating model required a custom product

For DWG's coffee business, ordering was one part of a broader operating loop. The product needed to connect account-specific supply with receiving and labeling, drink quality, equipment service, learning, and management finance. Baristas, account managers, and leaders needed different actions while relying on shared data and rules.

A packaged wholesale cabinet could have covered a basket and documents, but it would not have created the operating environment. We therefore designed a modular product and integration layer around those roles. This does not mean every company needs custom software. It illustrates the selection rule: uniqueness should exist in the process, not merely in the desire to own code.

Pre-selection checklist

If these questions have no answers, comparing subscriptions and estimates is premature. Run a short diagnosis with sales, operations, IT, and several real customers first. The output becomes a testable product brief rather than a wish list.

• which single process must become faster or less expensive;
• which accounts and roles will use the portal;
• which data they need and which system owns it;
• which rules cannot be adapted to a standard SaaS product;
• which APIs, exports, SLA terms, and exit conditions are mandatory;
• which metrics will be captured before launch;
• who owns support, training, and roadmap after release.