---
title: "Native Shopify B2B, a quote app, a custom build or CPQ: a decision guide"
description: "No winner, only fit: an 18-requirement matrix and a five-question tree for choosing between native Shopify B2B, a quote app, a custom build and CPQ."
url: "https://www.quotway.com/blog/shopify-b2b-native-vs-quote-app-vs-custom-vs-cpq"
type: "blog post"
category: "For Shopify agencies"
published: "2026-09-20"
verified: "2026-09-20"
shopify_api_version: "2026-07"
audience: "Shopify agencies and solution architects recommending a B2B quoting stack"
scope: "The four ways to run B2B quoting on Shopify, scored by requirement, with the conditions where each fits"
locale: "en"
source: "QuotWay - B2B Quote & Negotiation App for Shopify"
---

# Native Shopify B2B, a quote app, a custom build or CPQ: a decision guide

There is no winner among the four ways to run B2B quoting on Shopify, only fit.

Native Shopify B2B fits when prices are standing and the buyer orders against them. A quote app fits when the price is decided per deal on standard products and the deal has to become a Shopify order with its history. A custom build fits when the workflow itself is the product and the merchant has engineers who will keep pace with Shopify's quarterly API releases for as long as the store exists. CPQ fits when the product is configured from rules and the sales team already lives in a CRM opportunity. Most B2B stores end up with native B2B for standing prices plus one of the other three for the exceptions; the mistake is picking two that both want to own pricing.

This guide is for the agency or architect who has to recommend one. It defines the four options, scores them against eighteen requirements, and gives a five-question decision tree. The [architecture post](/blog/shopify-b2b-quote-architecture) explains why the ownership rule matters; [when you shouldn't use a quote app](/blog/when-not-to-use-a-shopify-quote-app) is the longer version of the native leaf; the [evaluation checklist](/blog/shopify-b2b-app-evaluation-checklist) is what to run against any app or build you shortlist, and the [launch test plan](/blog/shopify-b2b-launch-test-plan) is what to run before whichever one you choose goes live.

## The four options, defined

**Native Shopify B2B.** Companies, company locations and contacts; catalogs with price lists, quantity rules and volume pricing; net terms, vaulted cards and PO numbers at checkout; "submit for approval" to turn a checkout into a draft order; custom prices, locked prices and reserved stock on that draft; deposits and partial payments on Plus. On every plan since 2 April 2026. It has no object for a price request, a proposal, a counter-offer, an approval or a negotiation history. What you run: Shopify.

**A quote app.** A public app that adds the request, proposal versions, counter-offers, approvals and audit trail on top of the native objects, reads the buyer's catalog price as the starting point and creates the draft order when the price is agreed. Installed and removed by the merchant; the vendor carries API upgrades, compliance webhooks and storefront extensions. What you run: a subscription and the vendor's roadmap.

**A custom build.** The same quote layer written for one merchant, as a custom app on the Admin API with its own database, theme app extension, customer account extension and webhooks. Every behaviour can be exactly what the merchant wants. What you run: an application, for as long as the store trades - the obligations are listed below, and they do not shrink after launch.

**CPQ.** Configure-price-quote software, defined by one vendor as "software that helps sales teams configure products, apply pricing rules, manage discounts and approvals, and generate accurate quotes" - product configuration from rules, pricing governance, guided selling, approvals, documents and contracts, usually created from a CRM opportunity. Shopify is not its home: the storefront, the customer account and the draft order are an integration a CPQ project has to build or buy. What you run: a per-seat platform and its integration.

## The fit matrix

Fit is scored for the requirement as a B2B store on Shopify meets it, not in the abstract. "Partial" means the option can do it with a workaround or a second tool.

| Requirement | Native B2B | Quote app | Custom build | CPQ |
| --- | --- | --- | --- | --- |
| Company price lists, per location | Yes - catalogs | Reads them; never owns them | Reads them; never owns them | Partial - its own price book, synced to catalogs |
| Volume tiers | Yes - up to 10 breaks per product | Reads them | Reads them | Yes - own rules |
| Buyer orders and pays on terms | Yes | Yes - via the converted draft order | Yes - via the draft order you create | Partial - order capture is the integration |
| One review round before the order | Yes - submit for approval | Yes | Yes | Partial |
| Price request from a guest | No - prices need a company contact | Yes | Yes | No - quotes start from a CRM record |
| Deal-specific price, negotiated | No object | Yes | Yes | Yes |
| Buyer counter-offer | No | Yes | Yes | Partial - usually rep-driven |
| Approval on a discount, enforced | No - staff permissions scope accounts, not prices | Yes | Yes, if you build the enforcement | Yes |
| Custom or service lines with their own tax and shipping flags | Yes - on a draft order, by hand | Yes | Yes | Yes |
| Product configured from options and rules | No | No - holds a custom line, does not compute it | Possible | Yes - this is what CPQ is for |
| Complex engineered product, BOM-driven | No | No | Possible, at real cost | Yes |
| Freight priced per deal | Draft order, by hand | Yes | Yes | Yes |
| Multi-currency presentment | Yes - Markets | Yes, if the app quotes in the presentment currency | Yes, if built | Partial - CPQ currency vs Shopify currency |
| Deposit on the order | On Plus | On Plus, via the draft order | On Plus | On Plus, once it reaches Shopify |
| Quote inside the customer account | Draft orders only | Customer account UI extension | Customer account UI extension | No - CPQ portals are their own |
| ERP owns prices | Sync into catalogs | Reads catalogs | Reads catalogs | Own sync to CPQ and to catalogs |
| Quote created from a CRM opportunity | No | Partial - events via Flow | Possible | Yes - native |
| Time to first quote | Hours | Days | Months | Months |
| Ongoing engineering | None | Vendor's | Yours | Vendor's, plus your integration |
| Data ownership and exit | Shopify | Shopify + export | Yours | Vendor + Shopify |

Read the columns, not the rows. Native has the most "yes" cells for a store that never negotiates and the most "no" cells the moment it does. A quote app and a custom build share a column shape; the difference is who runs it. CPQ's column is strongest exactly where the others are weakest - configuration and CRM - and weakest where they are strongest - the Shopify storefront and order.

> **Decision tree: native, quote app, custom build or CPQ**
>
> Five questions in sequence. One: is the price known before the buyer asks? Yes leads to native Shopify B2B. No leads to question two: is the price computed from product options and rules? Yes leads to question three: do reps quote from a CRM opportunity? Yes leads to CPQ; no leads to a configurator plus a quote app or a custom build. From question two, no leads to question four: is there a workflow no app models, plus engineers to run an app for years? Yes leads to a custom build; no leads to a quote app. A note under the tree: most stores combine native for standing prices with one other option for exceptions.
>
> Five questions, four leaves. The tree is the short form of the sections below.

## Native Shopify B2B: when it is enough

Native is the answer when question 1 is yes for every buyer and every order: the price is on the location's catalog before anyone asks, tiers are quantity breaks that apply to everyone on that catalog, and the only review the merchant wants is a look at the draft order before it becomes an order. Since 2 April 2026 that is available on Basic, Grow and Advanced; Plus adds unlimited catalogs, direct catalog assignment to a company or location, deposits and partial payments. The eight situations native covers, each mapped to the feature that covers it, are in [when you shouldn't use a Shopify quote app](/blog/when-not-to-use-a-shopify-quote-app).

Native stops being enough at the first reply. A draft order can carry a custom price, but it has no state for "the buyer asked for less", no version, no approval and no record of the exchange. Merchants who try to run negotiation on draft orders end up with the conversation in email and the draft order out of date - which is the point at which one of the other three options is being chosen, whether or not anyone has said so.

## A quote app: when it fits

A quote app fits when the price is decided per deal on products Shopify already knows: the buyer asks, the seller proposes from the catalog price, one or both sides move, someone approves the discount, and the accepted version becomes a draft order at the agreed prices. It also fits the buyer native cannot serve - the guest who wants a number before they have a company account.

The conditions that make it the right choice rather than a custom build are practical. The workflow the merchant needs is the workflow the app models; the merchant has no engineering team, or has one with better things to do than track Shopify's quarterly API releases; time to first quote matters; and the app passes the [evaluation checklist](/blog/shopify-b2b-app-evaluation-checklist) - above all the native-fit questions, because an app that keeps its own price list has recreated the problem it was bought to solve. What it costs is the subscription and a dependency on the vendor's roadmap: a behaviour the app does not model is a feature request, not a ticket.

QuotWay is one such app and is the example this site can speak for: its [company-aware quoting](/features/b2b) starts a proposal from the buyer's company-location catalog price, versions every proposal and counter, enforces approvals on the server, and converts the accepted lines to a native draft order with the location's payment terms; the [Lite plan](/pricing) runs that whole loop free at ten quotes a month, which is a cheaper way to find out whether a store has quoting volume than any of the other three columns. Run the checklist against it the way you would against anyone else.

## A custom build: when it is justified, and what it must keep running

A custom build is justified when both halves of question 4 are true: there is a workflow no app models - a procurement rule, an industry document, a pricing negotiation that follows a contract's own logic - and the merchant will fund engineers to run an application for as long as the store trades. The first half is more common than the second, and agencies are usually asked to price only the first.

What a custom quote layer on Shopify has to keep running, from Shopify's own obligations pages:

- An Admin API version, upgraded on Shopify's quarterly cadence. Each version is supported for at least 12 months; a request to an unsupported version "falls forward" silently to the oldest supported one, which is how a build that nobody touched breaks in month thirteen. New apps are GraphQL only; the REST Admin API has been legacy since 1 October 2024.
- The three compliance webhooks - `customers/data_request`, `customers/redact`, `shop/redact` - and the protected-customer-data safeguards for any name, email, address or phone the build stores. A custom app is not reviewed for that access the way a public app is, but the requirements are the same.
- Webhook handling that survives Shopify's delivery model: verified signatures, duplicates ignored by `X-Shopify-Webhook-Id`, retries (8 over 4 hours, then the subscription is deleted), and a reconciliation job because delivery "isn't always guaranteed".
- Rate-limit-aware API use: 100 points a second on Standard, 200 on Advanced, 1,000 on Plus, with a 1,000-point cap per query.
- A theme app extension for the storefront and a customer account UI extension for the buyer's account, each with its own size limits and its own upgrade path; a headless storefront needs a third path.
- An idempotent conversion to the draft order, with the negotiated price on each line as a `priceOverride`, the company as the `purchasingEntity`, and drift checks against `draftOrderCalculate`.
- If checkout behaviour is part of the workflow - a PO-number rule, a validation - Shopify Functions; and "only stores on a Shopify Plus plan can use custom apps that contain Shopify Function APIs".

Two shortcuts look like custom builds and are not. Modelling the quote as metaobjects gives you a custom record type in the admin and on the Storefront API, but a record, not a workflow: no states, no versions, no approvals, no enforcement. And a Flow-and-draft-orders build - Flow automations moving a draft order through tags - is one review round with extra steps, and stops at the same reply native stops at.

A custom build stops being justified when the workflow it was built for turns out to be the one every quote app models. That happens more often than the reverse, and it is worth asking before the build, not after; the [architecture post](/blog/shopify-b2b-quote-architecture) is the specification either route should meet, and the [evaluation checklist](/blog/shopify-b2b-app-evaluation-checklist) is the test of whether an existing app already meets it.

## CPQ: when it is justified, and when it is overkill

CPQ is justified when question 2 is yes and question 3 is yes: the price comes out of product configuration rules rather than a conversation, and the people quoting work from CRM opportunities with contracts, renewals and guided selling around them. In that world Shopify is the order-capture and fulfilment surface, the CPQ is the quoting surface, and the integration between them - configured product to Shopify line, CPQ quote to draft order, Shopify order back to the opportunity - is a project of its own that the CPQ does not ship.

Full CPQ is overkill for the store whose products are standard, whose prices are negotiated rather than computed, and whose reps live in Shopify rather than a CRM. That is most Shopify B2B stores. The tell is the configuration rules: if a proposal's lines are variants at negotiated prices plus the occasional custom line, there is nothing for a configurator to configure, and the store is paying per seat for the two components it needs - approvals and documents - packaged with several it does not. The [Shopify CPQ post](/blog/shopify-cpq) separates the two jobs; [QuotWay versus enterprise CPQ](/compare/vs-enterprise-cpq) is the side-by-side for a store deciding between them.

The middle case - configured products, no CRM - is the dashed leaf on the tree: a product-options tool computes the configured price, and a quote layer (app or custom) negotiates and converts it. It is two tools because it is two jobs.

## Combining them

Every combination that works has one owner of the standing price, and it is Shopify's catalog.

- Native plus a quote app: the default for a store with standing prices and negotiated exceptions. Catalogs price the storefront and the reorders; the app quotes from the catalog price and hands back a draft order.
- Native plus a custom build: the same shape, for the store whose exceptions follow rules no app has.
- Native plus CPQ: CPQ owns configuration and the CRM-side quote; the ERP or CPQ syncs standing prices into catalogs; Shopify captures the order. The quote itself does not live in the customer account unless someone builds that.
- The combination that fails: any two options that both keep a price list. A quote app with its own prices next to catalogs, or a CPQ price book and catalogs both edited by hand, produces two numbers for one buyer within weeks.

## FAQ

### Can Shopify B2B handle negotiated pricing without an app?

For one round, yes: set the location to submit orders as drafts, adjust the prices on the draft order, lock them, and send the invoice. There is no object for the buyer's reply, a second version, or an approval, so a negotiation with more than one exchange needs a quote layer of some kind - app or custom.

### Can we implement request-a-quote without Shopify Plus?

Yes. Companies, catalogs, quantity rules, payment terms and draft orders are on every plan since April 2026, and a quote app or a custom app on the Admin API works on all of them. The Plus dependencies are Shopify's: deposits and partial payments, unlimited and directly assigned catalogs, and - for a custom build - Shopify Functions, which need a Plus store when they ship in a custom app.

### Does Shopify have a CPQ?

No. It has catalogs, quantity rules, draft orders and the B2B checkout; configuration rules, guided selling and CRM-native quoting come from CPQ platforms that integrate with Shopify, and negotiation on standard products comes from quote apps. Which one a store needs is question 2 on the tree.

### How do we estimate the cost of a custom build?

Price the obligations, not the launch: the API upgrade every quarter, the compliance webhooks and data safeguards, the webhook and rate-limit handling, the two extensions and their upgrades, and the conversion logic - each for the life of the store. A build estimate that ends at go-live is an estimate of the cheaper half.

### Which option keeps the data in Shopify?

Native keeps everything there. A quote app or a custom build keeps the negotiation - request, versions, approvals, audit trail - in its own store and everything else in Shopify, which is the correct split; the order is always Shopify's. CPQ keeps the quote in the CPQ and the order in Shopify, with the link between them as good as the integration.

### Can a quote app and a CPQ coexist?

Only with a clear border: one of them owns the proposal for a given product line. Two systems that can both propose a price to the same buyer is the two-price-lists failure in a different form.

## Sources

Shopify pages, all read on 20 September 2026:

- [B2B features by plan](https://help.shopify.com/en/manual/b2b/getting-started/plan-features) and [B2B for all - announcement, 2 April 2026](https://www.shopify.com/news/b2b-for-all)
- [Checkout and accounts](https://help.shopify.com/en/manual/b2b/checkout) and [creating B2B orders using draft orders](https://help.shopify.com/en/manual/b2b/checkout-and-orders/draft-orders)
- [Shopify Functions](https://shopify.dev/docs/apps/build/functions) and [metaobjects](https://shopify.dev/docs/apps/build/custom-data/metaobjects)
- [API versioning](https://shopify.dev/docs/api/usage/versioning), [REST Admin API - legacy notice](https://shopify.dev/docs/api/admin-rest), [GraphQL Admin API rate limits](https://shopify.dev/docs/apps/build/apis/graphql-admin/rate-limits)
- [Privacy law compliance - mandatory webhooks](https://shopify.dev/docs/apps/build/compliance/privacy-law-compliance) and [protected customer data](https://shopify.dev/docs/apps/launch/protected-customer-data)
- [Webhooks - verify deliveries, timeouts and retries](https://shopify.dev/docs/apps/build/webhooks/verify-deliveries) and [webhooks overview](https://shopify.dev/docs/apps/build/webhooks)
- [Theme app extensions](https://shopify.dev/docs/apps/build/online-store/theme-app-extensions) and [customer account UI extensions](https://shopify.dev/docs/api/customer-account-ui-extensions/latest)
- [Draft orders for B2B](https://shopify.dev/docs/apps/build/b2b/draft-orders) and [DraftOrderLineItemInput](https://shopify.dev/docs/api/admin-graphql/latest/input-objects/DraftOrderLineItemInput)
- CPQ definition, a vendor's own: [What is CPQ? (Salesforce)](https://www.salesforce.com/sales/cpq/what-is-cpq/)
