Back to Ledger
April 8, 2026

How sub-$1M makers should run a 30-day Shopify native B2B pilot before paying for a wholesale app

A narrow 30-day pilot with a few stockists is enough to test whether native Shopify B2B covers company setup, catalogs, payment terms, and collections before adding wholesale app cost.

The right first question is not whether native wholesale can do everything. It is whether it can handle your next few real stockists without creating manual work your team cannot maintain. For a maker under $1M, that means running a short pilot with a small account set instead of opening wholesale across the whole store. Pick three to five existing or likely stockists, and treat the next 30 days as an operating test rather than a channel launch. Your goal is to see whether buyers can be set up cleanly, see the right assortment and pricing, place an order without confusion, and pay on terms you can actually manage. Keep the pilot narrow enough that plan limits do not distort the result. If you spread wholesale pricing too broadly, or try to model every edge case on day one, you will not learn whether the native flow works. You will mainly prove that a rushed rollout creates cleanup work.

Build the pilot in the same sequence your buyer will experience it. First create each wholesale account as a company, not as a loose collection of customer notes. Attach the main contact and first location immediately so you are testing the actual account structure, not a placeholder. Choose the order-submission mode you want to live with during the pilot instead of deferring that decision. Then assign only the catalogs needed for those first accounts. This matters more than many operators think. A catalog is not just a price sheet. It is the control point for who sees what and at what price, which means sloppy catalog design creates confusion fast. On Basic, Grow, and Advanced, you have to respect the smaller catalog envelope and the dependency on the new Shopify Markets setup. Do not create extra variants of the same offer just because you can imagine future accounts needing them. For a 30-day test, treat one core wholesale catalog plus one or two tightly scoped exceptions as a practical pilot design choice, not a rule. After that, set payment terms at the company or location level, enable PO numbers if your buyers use them, and place at least one internal test order for each account pattern you expect to support. The test is not complete until someone on your side has seen the checkout, the order record, and the payment follow-up path with their own eyes.

A pilot can still give a misleading answer when the operator assumes the rollout to non-Plus plans means all B2B edge cases are now solved. That is the wrong read. The provided evidence still reserves some capabilities for Plus, including deposits, partial payments, and payment requests per fulfillment. If your first wholesale accounts need those workflows, a native pilot may still be useful, but it should be framed as a gap test, not a replacement decision. Another common mistake is forgetting that non-Plus catalog support depends on the new Shopify Markets setup. Teams can discover this late, after they have already promised account-specific pricing. A third failure mode is hitting the three active catalog limit on Basic, Grow, or Advanced before you have learned anything meaningful. If the pilot is structured around too many account-specific price lists, the plan ceiling becomes the story instead of buyer behavior. The payment side has its own risk. A saved card does not mean payment terms orders will collect themselves at expiry. If no one owns accounts receivable follow-up, overdue invoices will accumulate and the pilot will look worse than it should. Treat collections as an explicit workflow from day one.

At the end of 30 days, judge the pilot by friction, not by wholesale revenue alone. You want a plain answer to four operational questions. Could you set up each account without workarounds? Could each buyer see the right products and prices with minimal explanation? Could the order move through approval, checkout, and recordkeeping without side spreadsheets? Could your team reliably chase payment terms without inventing a new AR process? If the answer is yes on most accounts, defer the wholesale app and keep expanding natively in controlled steps. If the answer is no because you ran into genuine workflow gaps such as catalog scale, account-specific complexity, quoting needs, or payment behavior you cannot manage, then the pilot did its job. It told you where the app spend is justified. One last caveat matters here. Do not rely on reminder automation until you verify the live admin behavior in your own store. The source set contains a plan-matrix versus Flow-page tension around payment reminders and Plus requirements. That is exactly the kind of detail that should be checked inside the pilot rather than assumed from documentation alone.