How we think about an AI stack for e-commerce.

In four years we've rebuilt our AI stack three times. Each time because the old answer stopped scaling, stopped being affordable, or stopped fitting the GDPR requirements that have hardened in Dutch e-commerce since 2025. This piece isn't about the logos that show up on our stack page. It's about how we think when picking an AI stack for product-driven webshops, and the two building blocks that keep coming back.

Building block one: Claude as the engine under the chatbot

Since late 2025 our chatbots run on Claude. Three reasons it remains the most defensible choice after our tests.

Prompt caching is the first argument. A chatbot pushes the same few thousand tokens of system prompt and knowledge base through the model on every conversation. With proper caching you pay a fraction of the price on those input tokens instead of the full rate. For a client with a few hundred conversations per month that's tens of euros per month saved on API cost alone, and at higher volume it scales fast. No gimmick, just direct margin impact.

The second argument is language quality, and for the Dutch market that weighs heavily. We run the same test for every model: a conversation about sizing in lingerie, a topic where tone-mismatch leads directly to drop-off. Formal versus informal address, anglicisms, the difference between subtle nuances. Claude consistently wins that test against the well-known alternatives. For brands aiming for a premium feel, that's the difference between a chat that works and a chat you'd rather not put under your brand.

The third argument is more practical: tool use. Our chatbot doesn't just have to talk well, it has to take action. Save a lead, look up an order, escalate a conversation to a human. Since a few model versions back, that works in production without the edge cases we used to see (tools that didn't fire, or fired twice). In practice that's the difference between "the demo works" and "we trust this on a thousand conversations per month".

Building block two: Klaviyo for email flows

For clients on the Email-flows module we ship four base flows: welcome, abandoned cart, post-purchase, win-back. For product-driven e-commerce there's really only one serious choice there, and it's Klaviyo. Two reasons.

The Shopify integration is the deepest in the market. Klaviyo syncs real-time product data, customer events, and orders. Triggers like "Started Checkout" and "Order Fulfilled" are built in. No external middleware needed to catch those events, no patchwork between shop and mailing. That's exactly where competitors stumble: events are fragmentary, attribution is shaky, you don't know what a flow actually earned.

The second point matters just as much: per-flow revenue attribution is mature. Klaviyo tracks which orders can be attributed to each flow, with configurable attribution windows. That's essential for being able to tell a client: "this welcome flow generated €4,300 last month." For an agency delivering ROI reports, that distinction is the difference between "we're doing this well" and "look at what we delivered".

What we've written off

Two camps we deliberately walked away from. One: rule-based no-code automation tools for the serious work. Our key flows run as custom AI agents in code, not as visually-clicked workflows. Three reasons. The math gets bad at scale: once you have ten clients each running a few scenarios, you're paying per click. Version control is missing: a small bug-fix becomes UI work, not a git revert. And the narrative to clients is stronger when you can say "we build your agents bespoke" instead of "we set up pipelines in a no-code tool you could have learned yourself".

The trade-off is real: you write code instead of clicking. But code is reusable across clients, debuggable, version-controlled. For an agency scaling across multiple clients, that outweighs the initial setup speed of a no-code tool.

Two: marketing platforms without serious EU data residency. Our clients process personal data of EU citizens. We want to be able to demonstrate that data stays within EU borders, with daily backups, with point-in-time recovery, and with a valid data processing agreement. That rules out a few well-known American options, even when they're technically stronger. We host the whole stack EU-only in Frankfurt for the same reason.

What we let the client choose

One thing we explicitly don't do: prescribe a specific shop platform. Our chat widget integrates as a single script tag, so whether the client runs on Shopify, WooCommerce, Lightspeed, or a custom shop doesn't matter on our side. We keep that deliberately open: if a shop has been running well on a platform for years, we're not going to suggest they migrate because it suits us.

Three questions to ask any vendor

If you're considering an AI stack for your e-commerce right now, ask every vendor the same three things. What does this cost per month at five hundred conversations? Where does the data physically sit? And how do I roll back a misconfiguration? The answers tell you more about the vendor than any demo will.

Want our stack configured for your shop? In a short strategy call we look at your current tools, your data locations, and where we see simplification. Book via the button at the top or email info@dalvora.nl.