Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
66 changes: 66 additions & 0 deletions content/blog/2026-05-04-buyer-thinks-stack-is-custom.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
---
title: "The Buyer Thinks Their Stack Is Custom. You Have Shipped It a Dozen Times."
date: 2026-05-04
pillar: "The Constellation"
tags: []
linkedin_copy: |
Every merchant I talk to during replatform discovery believes their integration architecture is unique.

They are right about the details. They are wrong about the shape.

Mid-market commerce stacks cluster into a small number of recognizable compositions. Platform plus ERP plus OMS plus CDP plus ESP plus tax plus payments plus search plus reviews. The specific vendors vary. The architecture does not. An experienced integration architect has seen the composition before, including where the OMS sync will break under load and where the CDP ingestion will lag behind the ESP trigger.

This belief in uniqueness is expensive. It inflates discovery timelines. It lets implementation partners price exploration into every connection point, even the ones they have shipped four times before. It prevents the merchant from asking the one question that matters most: "Show me a reference architecture for a stack shaped like ours."

If the partner cannot produce one, that tells you something important.

The places where a merchant is genuinely unique exist. Maybe the loyalty program has an unusual earn-and-burn model. Maybe the fulfillment logic has warehouse-splitting rules specific to their distribution network. Those deserve full discovery.

The other eight integration points in the constellation do not. They deserve pattern-matching, not exploration.

A merchant who walks into a replatform understanding that their stack is a variation on a known theme, not a novel creation, will scope more accurately, negotiate more effectively, and hold their partner to a more specific standard.

The question is not "is my stack complex?" It is "which two or three parts are actually novel, and which parts has this team shipped before?"

The answer is always smaller than the merchant expects. That is good news.

Full post: {{url}}
---

Every merchant I talk to during a replatform discovery believes their integration architecture is unique. They have a specific ERP with specific customizations. Their OMS has a particular routing logic. Their loyalty program has an unusual points structure. Their tax engine has edge cases around nexus.

They are right about the details. They are wrong about the shape.

Mid-market commerce stacks cluster into a surprisingly small number of compositions. Platform plus ERP plus OMS plus CDP plus ESP plus tax plus payments plus search plus reviews. The specific vendors change. The shape does not.

Adobe Commerce with Algolia for search, Klaviyo or a comparable ESP for email, Avalara for tax, and a mid-market ERP. I have seen that stack, with minor variations, on more projects than I can count. Shopify Plus with a similar constellation is just as predictable. The merchant who arrives at discovery thinking they are a snowflake is, structurally, a pattern.

This matters because the belief in uniqueness is expensive.

When a merchant believes their stack is bespoke, they accept that discovery will take longer. They expect that estimation will be harder. They nod when the agency says "this is complex" because it confirms what they already believe about themselves.

But an experienced integration architect has seen the composition before. Not the exact vendor pairing, necessarily. The shape. The data flows. The failure points. The place where the OMS-to-ERP sync will break under load. The place where the CDP ingestion will lag behind the ESP trigger. The place where the tax engine will return unexpected results on bundle products.

These are not mysteries. They are patterns.

The merchant who recognizes this has an advantage. They can ask the implementation partner: "How many times have you shipped this composition?" Not "have you worked with our specific ERP." The specific ERP matters less than whether the team understands the shape of the integration between an ERP of that class and a commerce platform of that class.

The question that should happen in every discovery and almost never does: "Show me a reference architecture for a stack shaped like ours." If the implementation partner cannot produce one, either they have not done this before, or they have and they are not organized enough to reuse what they learned. Both answers are informative.

There is a second cost to the uniqueness belief. It distorts scoping.

When every integration is treated as net-new discovery, the SOW prices exploration time into every connection point. But if the team has shipped the same OMS-to-platform pattern four times, the discovery is not about figuring out what to build. It is about confirming that the merchant's instance matches the pattern and identifying the two or three places where it does not.

That is a different scope. A smaller one. A more honest one.

The places where the merchant actually is unique are worth finding. They exist. Maybe the loyalty program has a genuinely unusual earn-and-burn model. Maybe the fulfillment logic has a warehouse-splitting rule that is specific to their distribution network. Maybe they have a custom internal system that nothing integrates with natively.

Those deserve full discovery. The other eight integration points in the constellation do not. They deserve pattern-matching.

I am not arguing that mid-market merchants are simple. They are not. I am arguing that the complexity lives in a smaller number of places than most merchants believe, and that an honest implementation partner will tell them which parts are pattern and which parts are genuinely novel.

The merchant who walks into a replatform knowing that their stack is a variation on a known theme, not a unique creation, will scope better, negotiate better, and hold their implementation partner to a more specific standard.

The question to ask is not "is my stack complex?" It is "which parts of my stack are actually unusual, and which parts has this team shipped before?"

The answer will be smaller than you expect. That is good news.