Point of view

Commerce architecture fit for complex B2B: the decision layer before platform selection.

B2B ecommerce projects fail when the platform gets picked before the business logic is understood. Architecture fit flips that order. It starts with operational truth, pricing, accounts, approvals, inventory, and quote flows, and it ends with a platform recommendation defensible to the CIO, the CFO, and the VP of Sales. The work is short. The savings are not.

The thesis

The platform does not matter until the business logic is understood; architecture fit is the decision that determines whether implementation succeeds or stalls.

What's in this guide

Topics based on real decisions.

Skim by topic. Each section is grouped around a real decision that comes up in our discovery work with mid-market manufacturers and distributors choosing a commerce architecture before they choose a platform.

Commerce architecture fit is the match between a business operating model and the shape of the system that supports it. It covers how the ERP, the commerce platform, the integration layer, and the buyer experience are arranged. Architecture fit is the decision that determines whether the eventual platform choice succeeds or stalls, and it has to be resolved before platform selection makes sense.

Platforms are interchangeable; business logic is not. A platform that cannot honour customer-specific pricing, multi-warehouse inventory, approval chains, and account hierarchies will produce a storefront sales reps refuse to trust and customers stop using. The architecture is what determines whether the platform can carry the logic. The platform is a parts decision that follows the architecture decision.

For mid-market B2B businesses, a focused discovery and strategy engagement runs between two and eight weeks. Shorter than that and the operational truth is usually under-investigated. Longer than that and the project stalls in analysis. The output is a capability scorecard, an integration map, a roadmap, and a defensible platform recommendation the CIO and CFO can fund.

Native runs commerce inside or directly alongside the ERP. Middleware uses an integration layer to connect a separate commerce platform to the ERP. Decoupled splits the front end from the commerce backend so the buyer experience is custom while transactions stay on a known platform. Composable assembles best-of-breed services around the ERP. The right fit depends on ERP centrality, experience complexity, and the team's capacity to operate the stack.

Before. Shortlisting platforms before discovery means the architecture is being chosen implicitly by the platforms that made the cut, not by the business logic the architecture has to express. Discovery shapes the architecture; the architecture narrows the platforms; the platforms narrow the vendors. Reverse the sequence and the project is built on assumptions nobody validated.

It means the architecture partner is not paid by a platform vendor to recommend that vendor. Acro partners with Shopware, BigCommerce, Shopify, Acumatica, Cin7, and others, and the discovery work is structured so the recommendation is grounded in business logic rather than partner preference. Neutrality is a discipline in how the discovery is run, not a marketing line.

When the business logic is not documented, when stakeholders disagree on the customer journey, when the ERP is treated as a black box, or when the team that has to operate the site after launch is not in the discovery conversation. Pausing is the disciplined answer in those cases. Restarting from a stronger position takes weeks; restarting from a broken implementation takes quarters.

Celeste is an AI-assisted diagnostic that accelerates the first phase of discovery by asking the right operational questions and producing a structured first-pass read on the architecture options. It does not replace the human strategist. It compresses the time between an executive asking what to do and a recommendation worth funding. Use it as a starting point, then move into the human conversation that follows.

The ERP-centric pillar covers what operational truth looks like inside a manufacturer or distributor business. This architecture pillar covers how to translate that truth into a defensible architecture and platform decision. Read them together if you are scoping a major commerce project; read this one first if the platform decision is in front of you now.

Next step

Get the foundation right before you build.

For readers scoping a platform decision or wanting a full architecture recommendation.