Posted in Digital Commerce
June 8, 2026
point of view
Why the platform does not matter until you understand the business logic
Most B2B ecommerce decisions get made in the wrong order. The platform comes first, then the requirements get fit around what the platform can do. The right sequence is the opposite. Business logic first, architecture second, platform third. Platforms are interchangeable. Business logic is not. The decision that determines whether the project succeeds is the one that gets made before any platform appears in the conversation.
Key takeaway
Platforms are interchangeable; business logic is not. Sequence the decisions accordingly.
The cost of platform-first thinking
Platform-first thinking is rarely a conscious decision. A board member sees a demo. A consultant who only sells one platform shows up early. A peer company gets quoted in a trade publication and the shortlist contracts to one before the requirements are written. The platform is chosen by gravity, and the requirements get fit around it after the fact.
The cost shows up in the implementation. The customer-specific pricing model the contracts require does not match the pricing model the platform was designed around, so the integration grows a layer of custom logic that nobody fully owns. The multi-warehouse inventory the buyers need to see is not the inventory model the platform expects, so the storefront either lies or stalls. The approval chain the policy requires does not fit the workflow the platform ships with, so buyers abandon the cart at step three.
Each of those frictions traces back to the same root cause. The business logic was treated as a variable; the platform was treated as a constant. In mid-market B2B, the opposite is closer to the truth. The business logic has been refined over decades of customer relationships; the platform is a tool that gets replaced every five to seven years. Treating the older, more durable thing as the variable is what produces rescue engagements.
What business logic actually means in B2B
Business logic is not the documentation in the operations binder. It is the actual operating model of the company expressed in rules. Who can buy what, at what price, under what terms, with what approval, against what credit, shipped from which warehouse, with what surcharges, on what schedule. Each clause has nuance that depends on the customer, the product, the contract, and the situation.
A useful test: ask three people in three different departments to describe the freight calculation for a contract account. If you get three answers, that gap is business logic that exists in practice without existing in writing. The storefront will get one answer. The customer will get another. The audit will get a third. The cleanup costs more than the documentation would have.
Business logic in B2B has another property that B2C usually lacks: it is contractual. Customer-specific pricing is written into negotiated agreements. Approval thresholds are written into procurement policies. Freight programs are written into account-level terms. The storefront cannot make those rules up. It can only honour them. A platform that cannot honour them produces a digital experience that contradicts the paperwork the customer signed, which is how trust erodes.
How operational truth shapes architecture
Once the business logic is mapped, the architecture decision becomes tractable. Each rule gets two annotations: where it has to live, and what kind of integration it implies. Real-time call against the ERP, eventually consistent through middleware, owned by the commerce platform with write-back. Those two annotations produce a picture of how much ERP exposure the architecture requires, and that picture points to one or two architecture paths.
The picture rarely points to the platform a board member liked in a demo, because demos optimize for visual polish rather than operational fit. The picture points to the architecture the business actually needs, and the platform shortlist follows from there. Run that sequence and the platform decision feels obvious. Skip it and the platform decision feels like a coin flip, because it is.
This is the part of the work discovery and strategy is structured around. Not the kickoff workshop that surfaces personas. The structured sprint that surfaces operational truth and converts it into an architecture rationale a CFO can fund.
The right sequence: logic, architecture, platform
The disciplined sequence has three steps. Step one: surface and document the business logic with the people who run it. Step two: choose the architecture that can express the logic cleanly, with a written rationale and a named alternative that was considered and rejected. Step three: shortlist platforms that fit the architecture, score them against the capability matrix the discovery produced, and recommend the one that wins on fit and operating cost.
Each step constrains the next. The logic narrows the architecture options. The architecture narrows the platform options. The platforms narrow the vendors. By the time the team is comparing vendor proposals, the comparison is among options that have already been screened for fit. The proposal review becomes about implementation quality rather than platform suitability, which is a different and easier conversation.
Reverse the sequence and the comparison happens at the wrong layer. Vendors compete on platform features that may all be irrelevant to the business. The team chooses the vendor with the best demo, which is rarely the vendor whose chosen platform fits the operational truth. The mismatch surfaces six months into the build, when correction is at its most expensive.
What this looks like in a real engagement
A mid-market distributor we worked with came in with the platform already chosen. The board liked it. The shortlist was already down to one. The discovery sprint was scoped as a sanity check rather than a real architecture decision. Two weeks in, the business-rule catalogue showed that the chosen platform could not model the contract pricing the business depended on without significant customization.
The right call was to widen the platform shortlist and re-run the comparison against the architecture the catalogue implied. That meant going back to the board with a recommendation the board did not expect. Practical optimism includes the discipline to do that. The eventual platform decision was different, the build cost less, the launch hit its date, and the original platform would have produced a rescue engagement inside eighteen months.
The lesson is not that the original platform was bad. It was that the original platform was a poor fit for this particular operating model. A different business with a different model would have been well served by it. The decision is about fit, not about brand. Sequencing the work to surface fit before commitment is how the team gets the call right.
Related Articles
Commerce architecture fit for complex B2B: the decision layer before platform selection
- The architecture fit report: where B2B ecommerce projects fail before the first line of code
- ERP as source of truth vs commerce as source of truth
- The ERP-commerce readiness framework
- Why your ERP breaks when you bolt ecommerce on top
- Acumatica + DiamondBack Truck Covers
- Eagle Fence Distributing — Acumatica manufacturer spotlight
Frequently Asked Questions
Why does business logic matter more than platform choice in B2B ecommerce?
Because business logic is what the customer experiences and what the contracts require. Platforms are tools that get replaced every five to seven years; business logic is the durable operating model that platforms have to honour. Choosing the platform first means choosing what the business logic gets allowed to be, which inverts the natural authority of the operating model. Sequencing the decision the other way around produces a project that fits the business.
What does business logic mean in B2B commerce?
It is the operating model expressed in rules. Who can buy what, at what price, under what terms, with what approval, shipped from which warehouse, with what surcharges, on what schedule. In B2B the rules are usually contractual rather than catalogued, which is why mapping them in discovery is essential. The storefront has to honour the rules the customer's paperwork already established.
How long does it take to map B2B business logic?
For a mid-market business, two to four weeks of focused interviews and data review usually produces a defensible business-rule catalogue. The duration depends on how many product lines, how many customer segments, and how many people own the rules in practice. The catalogue becomes the input every later decision reads from.
Can a strong platform compensate for unmapped business logic?
No. A strong platform that does not match the business logic still produces a storefront the sales reps will not trust and the customers will quietly stop using. The strength of the platform is irrelevant if it cannot honour the rules the business runs on. Strength is in fit, not in brand.
What happens when business logic gets mapped late in a project?
The integration layer grows custom code to bridge the gap between what the platform can express and what the business actually requires. That custom code becomes a permanent operating cost and a source of regression risk every time the platform or the ERP gets upgraded. Mapping the logic earlier is dramatically cheaper than retrofitting it later.
How does this argument apply to a small B2B operation?
It applies even more cleanly. Small operations cannot afford the workarounds a large enterprise can absorb. A platform that does not fit the operating model produces a daily friction tax the small team is least equipped to pay. Sequencing the decision the right way is how a small team makes a single decision they can live with for seven years.
How does this connect to the ERP-centric pillar?
The ERP-centric pillar covers what operational truth looks like inside an ERP-driven business. This piece covers how to use that operational truth as the first input to the architecture and platform decisions. The two pieces are the same argument written from different angles; read them together if the project decision is in front of you.
Next step
Get the foundation right before you build.
For readers scoping a platform decision or wanting a full architecture recommendation.