Your Stack Is the Bottleneck. It’s Costing More Than Dev Time.

Inspired by the Fireside Chat: Execution Is the Advantage: AI, DXPs & the Future of Ecommerce Growth.

I spend most of my time talking to enterprise commerce teams about speed. Speed to launch, speed to test, speed to react when traffic shifts.

And every one of those conversations arrives at the same uncomfortable silence when I ask: “How many tools does your team touch between having an idea and getting it live on your site?”

The answer is usually somewhere between eight and twenty. The silence is because they’ve never counted. The discomfort is because, once they do, the number explains a lot of things nobody wanted to explain.

Your team isn’t slow. Your stack is making speed impossible. And it’s costing you far more than developer time.

The ‘Best-of-Breed’ Bet That Aged Badly

For fifteen years, the enterprise playbook was irresistible: buy the best analytics tool. The best testing platform. The best CMS. The best personalization engine. The best session replay. Best of everything. Stack them together, and you’d have the best stack.

Who’s going to argue with best-of-breed? It’s best.

Except now you’ve got twenty different point solutions that have never really agreed on what a “segment” means. Twenty separate data models, twenty separate logins, twenty separate vendor relationships – each one optimized for its narrow slice and utterly disconnected from the rest. It was always painful. But it used to be manageable pain.

It’s not manageable anymore. It’s become an existential bottleneck on your ability to do anything meaningful with AI.

Point solution number twenty gets infinitely smarter with AI? Great. It’s still a narrow slice through your ecosystem. It’s not helping you with the actual job – matching buyers with the best possible products, at speed, across a customer journey that AI has fundamentally reshaped. Your heat mapping tool got 100 times smarter. Wonderful. Everything else didn’t. That’s not a stack. That’s a collection of increasingly intelligent strangers who don’t talk to each other.

Why AI Works for Engineering and Not (Yet) for Commerce

There’s a question I hear constantly: why does AI seem to work so well for engineering teams but not for commerce and marketing teams?

The answer isn’t intelligence. It isn’t budget. It’s access.

Engineering AI has full-path access

When I use Claude Code or Codex, I’m not giving it one narrow slice of my workflow and asking it to optimize in isolation. I’m giving it full-stack, full-path access. It can read the codebase, set up development environments, write tests, deploy code, manage dependencies. It has license – safely, within a sandbox – to perform across the entire scope of the work. End to end.

That’s why it works. Not because engineering problems are simpler. Because the tool has access to the full context of the problem.

Commerce AI is trapped in silos

Now compare that to how most enterprise commerce teams use AI. The AI powering your analytics platform can only see analytics data. The AI in your personalization tool can only see personalization rules. The AI in your CMS can only see content. Each one is trapped in a silo, and there’s only so much that a local maximum inside a silo can do for your whole business.

Engineering AI vs. Commerce AI – in one line:

Engineering AI has full-path access. Commerce AI has a sliver. Same technology, different ceiling.

The problem isn’t that commerce teams aren’t ready for AI. The problem is that the system that surfaces the insight isn’t the system that lets you act on it. Those are different tools, owned by different vendors, connected by brittle integrations that somebody built three years ago and nobody wants to touch.

That’s the real bottleneck. Not your developers. Not your team’s ambition. Your architecture.

The Ambition Tax

This bottleneck doesn’t just slow teams down. It changes what they’re willing to attempt.

I see this everywhere: teams self-censoring their own ambition. Not because they lack ideas – because they’ve learned the cost of having one. A VP of Ecommerce spots an opportunity. AI-referred traffic is surging to a product category. The data suggests a radically different PDP layout could convert meaningfully better for that traffic source. The insight is clear. The idea is strong.

But that’s a three-month development project. It needs copy from someone. Design from someone else. A dev ticket. Vendor coordination. Segment setup in a tool that doesn’t share segments with the tool that needs them. So what happens? They round the corners on a button. They change some headline text. They test something safe – not because safe is smart, but because safe is all the architecture allows within a reasonable timeframe.

I call this the ambition tax. (I spent an embarrassing amount of time trying to find a better name. This one stuck because every CTO I’ve said it to immediately knew exactly what I meant – and then named three projects it had killed at their last company.)

The ambition tax (n.): The compounding cost of running ideas through a fragmented stack. Paid in slower campaigns, smaller experiments, and – worst – the experiments your team stops proposing because they’ve learned what asking costs.

Every fragmented stack collects it. Every handoff between tools adds to it. The cost isn’t just slower campaigns – it’s all the experiments that never get proposed, all the ideas that die in the gap between “we should try this” and “that would take too long.”

Teams that ship faster don’t just convert better. They learn faster. And learning velocity compounds into revenue over time. The ambition tax doesn’t just cost you one campaign. It costs you compounding knowledge you never acquired.

Even With the Right Stack, The Three-Week Brain Wins

The architecture problem is real. But even when teams have the right tools, there’s a second obstacle that’s purely psychological.

The three-week brain

When you’ve operated for years in a world where every campaign is a three-week project with handoffs at every stage, your brain calibrates to that pace. You expect a day of lag on every decision. You intuitively know that having three things in flight simultaneously is about the maximum before coordination costs start eating everything. You self-limit – not consciously, but structurally.

AI breaks the calibration

The shift to AI-augmented work breaks that calibration. Suddenly the normal course of action is ten things in flight at any given time. You’re not working on all of them. You have agents, a platform, and AI as a partner. But it requires rewiring yourself to think differently about what’s possible.

Some people find this intoxicating. They stop self-censoring. They realize that if one experiment out of ten fails, the cost is trivial – and the other nine are generating learning and revenue. They start proposing ideas they never would have attempted six months ago.

Others find it genuinely disorienting. The pace feels wrong. I had a CMO tell me last quarter: ‘This feels wrong. I shouldn't be able to move this fast.’ Both reactions are honest. But the gap between those two groups is shockingly binary – either AI is a transformative acceleration, or it’s underwhelming. There’s very little middle ground. The difference isn’t talent or budget. It’s conviction plus architecture plus willingness to let go of the three-week mindset. All three, or it doesn’t work.

Mindset Without Architecture Is Just Frustration

You can have the most AI-enthusiastic commerce leader in retail, but if every experiment still requires a dev ticket and three tool handoffs, enthusiasm becomes frustration fast. The architecture has to meet the ambition. The ambition has to meet the architecture. Most enterprises are stuck on one side or the other – either an excited team trapped in a slow stack, or a fast stack run by people still operating on three-week rhythms. Both fail. Differently, but both fail.

You Don’t Need to Replatform. You Need to Rethink the Layer.

One thing I want to be direct about, because I’ve seen too many enterprises get this wrong: you probably don’t need to get off the ecommerce platform you’ve been on for the last ten or twenty years.

That boring, monolithic ecommerce platform? It can happily serve up your product catalog. It handles transactions. It manages inventory. It does the infrastructure work it was built to do. In a lot of cases, a traditional monolithic platform is better infrastructure than a headless-everything approach where you’re expending infinite resources stitching together disaggregated services that sort of talk to each other if you’re lucky.

The problem was never the backend. The problem is the experience layer – the twenty tools sitting between your platform and your customer. The analytics overlays, the testing scripts, the personalization vendors, the CMS extensions, the frontend experimentation tools. That’s where the fragmentation lives. That’s where the handoffs happen. That’s where speed goes to die.

What you need is a single Workspace where insight and execution live in the same system. Where the same person who spots the opportunity can build the experiment, deploy it, and measure the result – without waiting on another team, another vendor, or another sprint.

(That’s the bet we’re making with Fastr Workspace.)

Three years ago, it would have been hard to argue against ‘best-of-breed.’ Today, enterprise leaders are telling me the opposite: best-of-breed is killing us. The question isn’t whether to consolidate. It’s how fast.

The Speed That Compounds

The teams that have made this shift – rethought the layer, consolidated the tooling, rewired the mindset – operate in a fundamentally different way. They run forty experiments a quarter instead of four. They react to traffic shifts the same day, not the same month. They build campaigns around AI-referred traffic patterns that didn’t exist six months ago.

The math changes. Not linearly – exponentially. A team running ten times more experiments isn’t just ten times faster. They’re ten times smarter about their customers by year’s end. Every experiment generates insight. Every insight fuels the next experiment. Speed creates knowledge. Knowledge creates advantage. Advantage compounds.

That’s what I mean when I say your stack is costing you more than developer time. It’s costing you the compounding velocity that separates the teams rewriting the rules from the teams still rounding rectangles.

The architecture decides which one you are. Not your people. Not your ambition. The system.