B2B dealer portal software: buy it or build it

Almost every "dealer portal software alternatives" page on the web is published by one of the vendors on the list, and the comparison ends the same way every time. We sell custom builds, so we carry the opposite bias, and the honest way to handle a bias is to write down the cases where it loses. That is what the first half of this page does: the situations where you should buy a subscription, or buy nothing at all, and close the tab.

Every figure below comes from the vendor's own page or from a named third-party listing, and every row carries its source. Where a vendor publishes nothing, that is recorded as a finding rather than filled in with a guess. Nothing here is a review. We have not run these products, and there is no verdict on product quality anywhere on this page.

The decision table

Every published number, in one place

Third-party estimates are labelled as such and are not vendor statements. Sana Commerce and OroCommerce publish no figure of their own, so the only numbers available for them come from outside sources of varying reliability, one of which is a direct competitor. Treat those rows as a starting point for a quote conversation, not as a price.

When a packaged product is the right answer

Start here, because this is the answer more often than not, and a custom build proposed into any of these situations is a proposal that should not have been written.

1. You have very few dealers. Three dealers who order twice a month do not need a portal. They need a current price list and someone who answers the phone. A portal earns its keep by removing repeated manual order entry, and where there is little repetition there is nothing to remove. Buy nothing, and revisit when the order count genuinely hurts.
2. Your process is standard reordering. Catalogue, customer-specific price list, reorder from history, order status, shipment tracking. That set is the exact feature list packaged products are built around, and rebuilding it from scratch buys you nothing you cannot subscribe to.
3. Your data already sits where a vendor supports it. If your catalogue and invoicing live in QuickBooks or Xero, Orderwerks names those integrations on its own site. If you run SAP Business One or Dynamics 365 Business Central, Sana's pricing page lists those ERPs against its tiers. A supported integration you subscribe to is faster and cheaper than a connector you commission.
4. You need to be live this quarter. Orderwerks publishes 2 to 4 weeks to go live, and that window is a configuration exercise on a product that already exists. Our own published timeline reaches the same 2 to 4 weeks for a single module, but only for a single module; a multi-department system is 4 to 8 weeks and a full platform is 3 to 6 months, so anything with an approval chain in it runs longer than a subscription would.
5. You want the option to stop. Orderwerks publishes no long-term contracts and cancellation at any time. If you are genuinely unsure whether dealers will use a portal at all, paying monthly to find out is the cheaper experiment. Run it for two quarters, then decide with usage data instead of with an opinion.
6. Nobody internally will own the system. A custom build assumes someone on your side answers questions about the process, signs off on rules, and keeps the dealer list current. Without that person, a subscription with a support desk behind it is the safer purchase.

If more than two of those describe you, the rest of this page is optional reading. Take the subscription, and spend what you saved on getting dealers to actually log in, which is the harder problem on either route.

When a custom build is the right answer

What pushes companies off packaged products is rarely a missing feature. It is that the decision logic sitting between an order and an invoice is specific to the company, and packaged products expose settings rather than logic.

1. Your pricing rules cannot be written as a price list. Cascading discount ladders, per-dealer contract terms with their own validity windows, volume tiers that reset annually, freight and currency rules that change the line total. Every packaged product supports customer-specific pricing; the real question is whether it supports your derivation of the price. Answer it by putting three genuinely awkward dealer agreements in front of a vendor during evaluation and asking them to configure all three live.
2. Credit and approval gate the order button. When "can this dealer place this order right now" depends on outstanding balance, a credit limit, an overdue invoice and a manager's approval, that chain is the system. It is the part we most often find rebuilt in a spreadsheet alongside a portal that could not express it.
3. Your ERP is not on anyone's supported list. Sana's published plans name SAP and Microsoft Dynamics products; Orderwerks names QuickBooks and Xero. If you run an in-house system, a regional ERP, or a national accounting package, the direct-integration argument does not apply to you, and you will be commissioning connector work whichever side you choose. At that point the decision is between a connector into someone else's data model and a system built on your own.
4. Portal accounts grow with your dealer network. Per-user and volume-based billing behave very differently when the accounts belong to your dealers' staff rather than your own. Orderwerks publishes a per-user base rate alongside "Customer accounts tiered by count - not per-user", and the third-party figure for OroCommerce Enterprise is described as aligned to GMV bands. Project your own growth curve into whichever unit applies before you compare headline numbers.
5. Ownership is a procurement requirement. Some buyers need the source code, an on-premise deployment, or a licence that does not renew. Our model is a one-time payment with unlimited users and source code delivered under contract. That exists precisely for this requirement and is worth nothing to a buyer who does not have it.
6. The portal is one part of a larger system. If the same project also covers production, dispatch or field service, the portal is a module rather than a product, and buying it separately creates a second system to reconcile. Our dealer portal page sets out what we build into a portal and what we deliberately leave in the ERP.

How the ERP connection actually differs

This is the section most comparison pages skip, and it is the one that decides whether the portal shows the truth. Three patterns are published by the products above.

• Direct read and write against the ERP. Sana Commerce states that its integration is direct, with no middleware, no manual syncs and no separate database to maintain. A write-up by Virto Commerce, itself a competitor, describes the deployment as single-tenant SaaS on Azure that reads from and writes to the ERP so that customer-specific prices, stock levels and order history reflect live ERP data. The trade is scope: this works for the ERPs the vendor has built for, which is why the supported list matters more than the feature list.
• Sync out, push back. Orderwerks states "Products sync from QuickBooks. Approved orders push back as invoices." The portal holds its own copy of the catalogue and returns approved orders as accounting documents. This is simpler to operate and puts a defined boundary between the two systems; it also means "live" is a question of sync frequency rather than a read-through.
• Write the connector yourself. OroCommerce publishes its source under the Open Software License version 3.0, so the connector is your code, on your schedule, against your ERP. A custom build is the same position without a platform's assumptions attached: you decide field by field what is read live and what is cached, and you decide what the portal does when the ERP is unavailable.

Whichever route you take, ask the same four questions in the demo. Which of my ERP's fields do you read live, and which are copied? What is the sync interval, and what happens to an order placed during an outage? Who owns the connector and its configuration when the contract ends? And what does it cost to add a field that my ERP has and your data model does not? Vendors answer these readily. The answers are what actually separate the options, and none of them appear in a feature grid.

Switching cost and lock-in

The common mistake in a buy-or-build comparison is not choosing wrongly. It is comparing a monthly number against a one-time number without a shared horizon. So do the arithmetic in public.

Take Orderwerks' published figures at face value. The base platform at $60/user/month for five internal users is $300 per month at the headline rate, which is $18,000 over five years, plus onboarding from $2,500, plus the B2B eCommerce Portal add-on that is "Priced per setup" and therefore not knowable in advance. Treat that as a ceiling rather than a quote: the same pricing page offers volume pricing for teams of five and above, so ask for the real rate at your seat count before you compare anything. At the alternative published entry point of $100/month, the five-year subscription line is $6,000 before any add-on. For Sana Commerce there is no vendor figure at all; the third-party estimate begins at $10,000 per year with implementation from $5,000, which puts a five-year floor at $55,000 if that estimate holds. For OroCommerce, running the open-source edition costs nothing in licence and everything in engineering, while the third-party figure quoted for the commercial edition begins at $45,000 per year.

Against those, our published bands are one-time: $3,000 to $6,000 for a single module, $8,000 to $15,000 for a multi-department system, $20,000+ for an end-to-end platform, with maintenance optional at 12% to 25% per year and source code delivered. The shape is different, not universally better. A build is worse in year one and flatter afterwards, and it carries a risk a subscription does not: if the thing you commissioned is wrong, nobody refunds a project fee.

Lock-in is not a property of one model. It is four contract questions that apply to both:

1. Export. Can you take out the catalogue, dealer accounts, price agreements and full order history in a documented format, on demand, and who pays for that? Get the answer in writing before signing, not in the month you want to leave.
2. The connector. Who owns the integration code and its configuration when the relationship ends? This is the piece that is most expensive to rebuild and the one most often left unaddressed in a contract.
3. Price changes. What notice applies, and what is the renewal mechanism? A subscription is a decision you make again every year, which is useful while the product is working and an exposure when it is not.
4. Dealer logins. Your dealers took months to adopt the portal. A migration that resets their credentials spends that adoption a second time. Ask both sides how identity moves.

How to run this evaluation in a week

1. Count the orders, not the dealers. How many order lines per month currently arrive by phone, email or messaging app, and how many minutes does each one cost to key in? That number is the entire business case, and it is the one people skip.
2. Write down your three most awkward dealer agreements. Not the standard one. Take them into every demo and ask the vendor to configure them live. A packaged product that handles all three is your answer, and you are done.
3. Name your ERP and check the supported list. If it is not there, the shortlist changes shape immediately, and the decision becomes which data model you want to own.
4. Multiply both options over five years and add implementation to each. Include the add-ons that are priced per setup by asking for them as a quote rather than leaving them blank.
5. Ask the four exit questions above of every vendor on the list, ourselves included.

If that process lands on a subscription, take the subscription. We say the same thing on our comparison hub, which sets out where packaged products win against custom development on ERP, WMS, field service and project management. We would rather lose a project than deliver one that should have been a $100 per month product.

Sources

• Orderwerks, Dealer Portal (orderwerks.com), for the starting price, per-transaction fees and go-live window
• Orderwerks, Pricing (orderwerks.com), for the base platform rate, add-ons, onboarding and contract terms
• Orderwerks, home page (orderwerks.com), for the named accounting integrations
• Sana Commerce, Pricing (sana-commerce.com), for the plan names, the Request Pricing route, the ERPs listed per plan and the integration statement
• Sana Commerce on Capterra (capterra.com), for "Contact vendor for pricing"
• Sana Commerce pricing estimate (itqlick.com), a third-party licence and implementation estimate
• Virto Commerce on Sana Commerce alternatives (virtocommerce.com), for the deployment and ERP integration description, published by a competitor
• OroCommerce repository and its licence file (github.com), for the open-source description and the Open Software License version 3.0
• OroCommerce on GetApp (getapp.com), for "No pricing info"
• B2B commerce platform pricing guide (rigbyjs.com), a third-party OroCommerce Enterprise range
• Growmax, Sana Commerce alternatives (growmax.io), for its own pricing model and for its claims about a competitor
• KodDelta pricing and delivery bands

Vendor pages checked in August 2026. Prices change without notice and regional terms differ, so verify the linked page before deciding. Product names belong to their respective owners. KodDelta is an independent third-party developer and is not a partner, reseller or implementation partner of any product named here, and nothing on this page is a review or an assessment of product quality.

Frequently asked questions

Which dealer portal vendors publish a price?

Of the products checked in August 2026, only Orderwerks publishes figures on its own site: "Pricing starts at $100/month. No per-transaction fees." on its dealer portal page, and a $60/user/month base platform plus a $2,500 starting onboarding fee on its pricing page. Sana Commerce lists three plans (Essential, Pro, Advanced) behind a Request Pricing form with no numbers. OroCommerce is open source under the Open Software License version 3.0, and GetApp records "No pricing info" for it. Growmax describes its own model as "Custom pricing".

When should I buy a SaaS dealer portal instead of building one?

Buy when your process is standard B2B reordering, your catalogue and prices already sit in a system the vendor supports, and you want to be live this quarter rather than next. Orderwerks states "Most manufacturers are live within 2-4 weeks" and publishes no long-term contracts with cancellation at any time. If you have only a handful of dealers, buy nothing at all: a shared price list and an email inbox is cheaper than any portal, and a portal will not fix a volume problem you do not have.

When is a custom dealer portal the right answer?

When the decision logic is the product. Cascading discount ladders, per-dealer contract terms, credit limits that gate the order button, and multi-step approval chains are the parts that do not fit a settings page. Also when your ERP is not on any vendor supported list, when portal accounts grow with your dealer network so per-user or volume billing works against you, or when your procurement requires source code delivery.

How do dealer portals connect to an ERP?

Three published patterns. Direct read and write against the ERP: Sana Commerce states its integration is direct, with no middleware, no manual syncs and no separate database to maintain, and lists SAP and Microsoft Dynamics products by name. Sync out and push back: Orderwerks states "Products sync from QuickBooks. Approved orders push back as invoices." Write the connector yourself: OroCommerce ships as open source, as does a custom build against your own ERP. The first question to ask any vendor is whether your specific ERP is on the supported list.

What does it cost to leave a dealer portal later?

Ask four questions before signing, not after. Can you export the catalogue, dealer accounts, price agreements and order history in a documented format, and who pays for that export? Who owns the ERP connector and its configuration? What notice applies to a price change? And what happens to dealer logins during a migration? Subscription products are cheaper to start and carry a renewal decision every year; a one-time build costs more on day one and carries no renewal, which is why the comparison only resolves once both are multiplied over the same number of years.