MAXBURST is an enterprise WordPress and WooCommerce agency, a Pressable partner, and a Shopify Solution Provider. We build on both platforms. This article is about where the line falls between them, and why complex industrial companies keep landing on the wrong side of it.
Somewhere in most manufacturing companies there is a meeting where someone says “we should be selling more through the website,” and someone else says “what about Shopify?”
It is a reasonable thing to say. Shopify is the default mental model for putting products online, and it earned that position honestly. It is a genuinely excellent platform. We build on it, we sell it, and we have shipped Shopify stores we’re proud of.
But the question is usually being asked one layer too late. Before you evaluate ecommerce platforms, it is worth establishing whether you are running ecommerce at all.
For a large share of manufacturing, aerospace, engineering, and industrial B2B companies, the honest answer is no. Not in the sense Shopify means it. Most of the industrial catalogs we build never process a payment.
Transaction primitives vs. specification primitives
Every commerce platform is built around a primitive: the smallest unit of business logic everything else assembles from. Shopify’s primitive is the transaction. Product, variant, cart, checkout, order. That model is coherent, deeply optimized, and it is the reason Shopify converts so well for retail. Every feature Shopify ships is downstream of it.
Industrial B2B usually runs on a different primitive: the specification.
A procurement engineer sourcing a laser system is not shopping. They are matching requirements. Wavelength, pulse width, pulse energy, repetition rate, duty cycle, integration envelope, lead time, certification class. The output of that process is not an order. It is a shortlist, then an RFQ, then a technical conversation, then a quote, then a PO issued through a system that has nothing to do with your website.
The website’s job in that sequence is not to close a transaction. It is to let a technical buyer establish fit without talking to anyone, and to hand a qualified, pre-contextualized inquiry to your sales engineer.
You can build that on Shopify. People do. But you are building a specification system inside a platform whose every abstraction assumes a transaction, which means you spend your budget translating between the two rather than on the thing you actually needed.
A six-question test
Before anyone names a platform, answer these. They apply across every sector we work in. They are ordered roughly by how much weight we’d give them.
1. Can a buyer complete a purchase without a human? If most revenue requires a quote, an approval chain, or a negotiated price, checkout is not your core problem. Discovery and qualification are.
2. Is your product defined by more than three variable attributes? Not “does it have three options in your catalog.” Does the buyer select on more than three axes to arrive at a part number?
3. Does your product data live somewhere else already? An ERP, a PIM, a PLM system, a SQL database, or the twelve-year-old spreadsheet that is functionally your PIM. If the website is a view onto an upstream system of record, integration architecture matters more than commerce features.
4. Does a product carry documents as first-class data? Spec sheets, CAD files, RoHS or REACH declarations, material certs, test reports, drawings. Are these part of the product record, or attachments bolted onto it?
5. Do different buyers need to see different catalogs? Distributors, OEM accounts, direct, international, government. Not just different prices. Different visible product sets.
6. Does fulfillment involve rules more complex than one warehouse, one carrier? Split shipments, freight quoting, hazmat, export control, drop-ship from plant.
Two or fewer yes answers and Shopify is probably the right call, and we would tell you so. Four or more and you are building a specification system, and you should choose your platform on data modeling and integration, not on checkout.
Let’s correct the record on Shopify first
A lot of “Shopify isn’t for B2B” content on the internet is running on 2022 information. If we’re going to argue this, we should argue against what Shopify actually is today.
Shopify has real, native B2B. Company accounts with multiple buyers and multiple locations. Customer-specific catalogs and price lists. Net payment terms. Purchase order numbers at checkout. Quantity rules and case-pack minimums. Self-serve reordering. Shopify Flow for automation. This is not app-store duct tape; it is in the core object model. It launched on Plus and, on April 2, 2026, Shopify extended the foundational set to Basic, Grow, and Advanced at no extra cost: company profiles, up to three custom catalogs with tailored pricing, volume discounts and quantity rules, vaulted credit cards, and payment terms.
The variant ceiling story is also out of date. Shopify raised the limit from 100 to 2,048 variants per product in October 2025, on every plan, at no extra cost.
If someone tells you Shopify can’t do wholesale pricing or company accounts, they haven’t looked in three years. Take that objection off the table. The real constraints are more specific and more interesting.
Where it actually breaks for industrial catalogs
The three-option cap. Shopify raised the variant count to 2,048 but left the option limit at three. A product can vary along Size, Color, and Material, and that is the ceiling on native option axes. For a configurable industrial product varying by material, finish, thread pitch, pressure rating, connection type, and certification class, three axes is the wall, and the variant count never mattered. The standard workaround is to push extra dimensions into metafields and render a custom selector against the Storefront API, which works, and which means you are now maintaining a custom product configurator outside the platform’s data model while still paying for the platform’s data model.
200 metafields per resource. That’s the ceiling on custom fields per product, shared between your own fields and anything installed apps write. Industrial products with full technical specifications, compliance attributes, and document references consume that budget faster than people expect, and you don’t discover it during the demo.
Three catalogs below Plus. The April 2026 expansion brought B2B to every paid plan, but capped active B2B catalogs at three on Basic, Grow, and Advanced. Unlimited catalogs, and direct catalog assignment to specific companies and locations, remain Plus-only. If you segment by distributor, OEM account, direct, international, and government, you are at four or five before you have finished listing your channels. There is also a prerequisite that is easy to miss during scoping: Shopify’s documentation states that B2B catalog features on those plans require the store to be on new Shopify Markets, so an existing store on the older setup has a migration before it starts.
One customer, one company. A single customer record cannot be both a B2B and a B2C buyer in the same store. One company assignment per customer, with separate accounts as the workaround. For a manufacturer that sells both directly and through a distributor network, where the same customer may purchase in both ways, discovering that limitation late in the process creates an uncomfortable constraint.
API rate limits, which are the real ERP story. Shopify’s REST Admin API allows roughly 2 requests per second on Basic and Shopify plans, 4 on Advanced, and 20 on Plus. If you are syncing a large catalog with an ERP, doing nightly inventory and pricing reconciliation across thousands of SKUs, or pushing near-real-time availability, those numbers are a hard planning constraint. This is where “Shopify integrates with everything” collides with arithmetic. It is solvable with batching, queuing, GraphQL, and bulk operations, but you are engineering around a throughput budget you do not control and cannot raise except by changing plans.
Ten inventory locations below Plus. Multi-plant manufacturers and distributors with regional warehouses hit this quickly.
The metafield limit episode, which is the ownership argument with a date on it. In February 2026 Shopify announced it was cutting metafield write limits from 2MB to 16KB in API version 2026-04. That change would have broken a meaningful number of product configurators and B2B pricing implementations. Developers pushed back publicly, and Shopify revised the cap to 128KB for JSON metafields and 64KB for other types, grandfathering existing apps.
That story has a happy ending, and it is still the argument. A decision that would have broken production systems was made unilaterally, on the platform’s timeline, and reversed because the community complained loudly enough. That is what building on rented infrastructure means. Not that the landlord is malicious, but that the roadmap is not yours and your remediation window is whatever they decide it is.
And the one Shopify still doesn’t do natively: quote-to-order. RFQ workflows, quote versioning, approval routing, quote-to-order conversion. These remain app or custom territory even on Plus. For companies where the quote is the transaction, the platform’s most-optimized surface, checkout, is the surface they will use least.
The pattern most manufacturers actually need: WooCommerce with checkout turned off
Here is the thing that surprises people when we scope a manufacturing project.
Most of the WooCommerce sites we build for industrial clients do not sell anything. No checkout. No payment gateway. No PCI scope at all. We deploy WooCommerce in catalog mode, use it as a product data framework, and never enable the transactional layer.
That sounds like a strange choice until you look at what WooCommerce actually is underneath the store. Strip away cart and checkout and what remains is a mature product data system: a product object with unlimited attributes, hierarchical and non-hierarchical taxonomies, variations without an arbitrary option ceiling, media and document relationships, a REST API, and a query layer that plugs into the entire WordPress ecosystem. That framework is what an industrial catalog needs. The commerce is optional.
It is the most common shape of project we take on, and it is almost never what the client came in asking for.
So the site does what the business actually does. Products with full technical specifications as structured, filterable data. Spec sheets, CAD files, drawings, and compliance documentation attached as first-class related records rather than PDFs in an uploads folder. Faceted search across engineering attributes. Gated documentation behind a distributor login. Request a Quote where a retail site would have Add to Cart.
This is the option Shopify structurally cannot offer. Shopify is a transaction engine. A Shopify store with checkout disabled is not a lean catalog platform; it is a transaction engine you are paying for and not using, whose data model still constrains you to three option axes and 200 metafields, and whose entire feature roadmap is being built for a use case you don’t have. There is no version of Shopify that is “the good parts for a catalog.” The transaction is the product.
The hybrid: a cart that isn’t a cart
Couristan runs a variation on this that’s worth describing, because it’s where most industrial companies eventually land.
Their catalog spans residential carpet, area rugs, custom rugs, runners, indoor/outdoor products, and contract and hospitality flooring, serving homeowners, designers, dealers, hospitality buyers, and commercial trade at the same time. There is an Add to Cart control on the site. It does not take payment and it never will.
It’s a quote basket. A designer or dealer assembles a multi-line selection across collections, and rather than routing to checkout it submits into Salesforce as a structured opportunity with product context attached, where the sales team picks it up and prices it.
Architecturally, that is a specification workflow wearing transaction clothing. Cart UI is the right interface pattern because buyers already understand it, and reaching for the existing WooCommerce cart object saves you from building a line-item assembler from scratch. But everything downstream of it is CRM integration, not commerce. The cart object gets repurposed as an RFQ container, the submit handler talks to Salesforce instead of a payment gateway, and product data flows into the CRM record so the sales conversation starts with context instead of “what were you looking at?”
You can approximate this on Shopify with draft orders and an app. What you cannot do is decide that checkout, the platform’s most heavily optimized and most heavily constrained surface, simply isn’t part of your architecture.
Two projects, two primitives
A laser manufacturer with no cart at all. Photonics Industries International builds diode-pumped solid-state laser systems for industrial microprocessing, scientific research, medical, defense, and OEM applications. Buyers are engineers, researchers, integrators, and procurement teams arriving with an application rather than a part number. They may know they need femtosecond pulses, or UV nanosecond output, or a specific harmonic wavelength for semiconductor processing or Ti:Sapphire pumping, without knowing which product series maps to that requirement.
Pure catalog mode. The conversion event is Request a Quote, and the entire architectural problem is helping a technical visitor traverse from application to laser family to specification confidence, then hand sales an inquiry with context attached.
The information architecture is organized around pulse regimes, wavelengths, and applications rather than around a product-and-variant tree, because that is how the buyer’s search actually decomposes. A laser series is specified along four dimensions at once — optical, electrical, mechanical, environmental — and a buyer’s constraints rarely respect those boundaries. Sub-10-picosecond pulses at 355nm, above 20W average power, air-cooled is an ordinary inquiry, and it spans three of the four. No retail taxonomy has a concept of a filter set like that.
On a transaction-primitive platform, that structure is something you fight the CMS to express. On an open content model it is just how you define your post types and taxonomies on day one.
A century-old flooring brand and a database that couldn’t keep up. Beyond the quote basket described above, Couristan’s harder problem was upstream.
Their product data lived on a third-party Microsoft SQL server external to the site. Search and browse queries against it produced frequent timeouts and general slowness. That is not a design problem or a theme problem. It is a data architecture problem, and it is the single most common technical failure we see in established manufacturers and distributors: the catalog is real, the data is real, and the website is a slow window onto a system it does not control.
The fix was to take the external server out of the request path entirely. The catalog was migrated into WordPress, running on a stack Couristan controls, so a search stopped being a round trip to a third-party host and became a local, indexed query. The bottleneck was removed rather than tuned around.
What that bought them was not just speed. Once the product data lived in a structure they owned, it could be modeled properly — which is what made everything after it possible, including the quote basket described above and the AI discovery layer running on top of the catalog today.
The interesting constraint in that project was never checkout. It was how product data gets from an upstream system of record into a fast, searchable, filterable front end serving four distinct audiences with four different definitions of “relevant.” Solving it meant control over the data layer: how records are ingested, indexed, cached, and queried.
That control is exactly what a closed platform does not give you. On Shopify, the upstream database becomes an import problem constrained by an API rate limit, and the query layer is whatever the platform provides.
What the open stack actually buys you
Not “flexibility.” That word means nothing. Specifically:
A data model you define. WordPress custom post types, custom taxonomies, and custom fields let you represent a product the way your engineers represent it. Six selection axes, not three. Specification attributes as structured, queryable data rather than a spec-sheet PDF the site can’t read. Documents, certifications, and CAD files as first-class related objects. No metafield budget.
Integration on your terms. You are not negotiating with an app store or a rate limit. You write the connector to your ERP or CRM with the sync topology the situation calls for: real-time where it matters, scheduled where it doesn’t, cached and indexed where read performance is the constraint. When the upstream system is Epicor or NetSuite or Acctivate or Salesforce or something written in-house in 2009, that flexibility is not a nice-to-have.
Commerce as a module, not a foundation. WooCommerce is a plugin. That is the architectural point people miss, and it is why catalog mode is even possible. Transactional commerce is one capability among several, sitting alongside quote routing, dealer portals, document libraries, and technical content. You can run for years with no checkout, then enable real commerce on one product line without replatforming, because commerce was never load-bearing.
Real URL and schema control. Industrial buyers increasingly begin research inside AI assistants rather than a search box, asking a model to compare suppliers or explain a spec before they ever reach a website. Being legible to those systems depends on clean URL architecture, precise structured data, and technical content a parser can actually resolve. Shopify emits schema and its themes are editable, so this is a matter of degree rather than a hard blocker, but degree matters when your entire differentiation is technical specificity.
What it costs you, honestly
Any agency that tells you the open stack has no downside is selling you something.
WordPress product queries degrade at scale if you let them. WordPress stores custom fields in a key-value table, which is enormously flexible and gets slow when you filter a large catalog across eight attributes simultaneously. WooCommerce’s High-Performance Order Storage moved orders to dedicated tables, which fixed the order side. Product attribute querying is still yours to engineer. Done badly, you get a faceted search that takes four seconds. Done properly, you build custom indexed lookup tables or push search to Elasticsearch and it is fast at any catalog size. This is a solved problem, but it is solved by engineering rather than by installing a plugin, and it is the single biggest reason WooCommerce sites underperform.
You own the maintenance and the security surface. Plugin dependencies, update discipline, patch cadence. This is a real transfer of responsibility and it is the strongest honest argument in Shopify’s favor.
It’s worth noting that catalog mode narrows this considerably. No checkout means no payment gateway, no cardholder data, and PCI DSS scope that is largely eliminated rather than managed. For a company weighing Shopify specifically because they don’t want to think about payment security, the catalog-only pattern removes the concern by removing the payments.
Which leaves infrastructure, and that is where hosting stops being a commodity decision.
Where Pressable fits
The operational appeal of Shopify is genuine. Someone else handles scaling, patching, backups, uptime, and the 2 a.m. incident. That is worth real money, and it is the thing companies are actually buying when they say they want something simple.
Managed WordPress infrastructure gives you that same operational profile without the ownership tradeoff. We build on Pressable, which is part of Automattic, the company behind WordPress.com, WooCommerce, and Jetpack. The platform layer is managed the way Shopify’s is: infrastructure, scaling, security at the host level, backups, staging environments, deployment workflow. What you keep is everything Shopify doesn’t let you keep. The code is yours. The database is yours. The data model is yours. You can migrate, extend, fork, or export on your own schedule.
For a regulated manufacturer, an aerospace supplier, or a defense-adjacent business, that distinction is a compliance and continuity question, not a philosophical one.
We use Pressable because after enough enterprise builds we concluded it is the right host for complex, integration-heavy WordPress in these industries, and because being close to the team that builds WooCommerce is useful when a client’s requirements run past the documentation.
The discovery layer
One more thing the open architecture makes possible, which is worth mentioning because it is increasingly what clients ask for.
We built VectorAIQ as an AI engagement layer for exactly the problem both projects above share: a technical buyer who knows their application but not your product taxonomy. It lets a visitor describe what they need in their own language and get guided toward the right product family, the right spec sheet, the right resource, or the right person.
That only works with deep, structured access to the full catalog and content graph, including all the specification attributes that would never exist in a transaction-shaped data model. Which is another way of saying it is a natural extension of an open data layer and an awkward bolt-on to a closed one. The site that models its own products properly is the site that can build intelligence on top of them.
When Shopify is the right answer
We would recommend Shopify, and have, when:
- Products are genuinely simple and vary on three axes or fewer
- Buyers can and do self-serve to checkout without a quote
- Speed to market matters more than data model precision
- The team has no technical resource and no appetite for one
- You want the operational burden entirely off your plate and are willing to trade control for it
- You are selling B2C alongside B2B and want one system for both
That describes a lot of companies. It does not describe most manufacturers.
The mistake isn’t choosing Shopify. It’s choosing a platform before deciding what kind of system you are building, and then discovering eighteen months in that half your budget went to making a transaction platform behave like a specification platform. Or, more often, buying a checkout you never turn on.
Talk to us
MAXBURST builds engineering-grade web systems for manufacturing, aerospace, engineering, and industrial B2B companies. We work on WordPress and WooCommerce with Pressable, and we work on Shopify, and we will tell you honestly which one your requirements point to.
If your current site is fighting your business, the platform was probably chosen before the requirements were understood. That is a fixable problem.
Schedule a Technical Platform Assessment | maxburst.com | hello@maxburst.com
