"Your Tech Stack Is Probably Costing You More Than You Think" - A Pulse Commentary

In the run up to the Pulse eCommerce Summit on the 13th - 14th May 2026, we are launching a series of commentary pieces on topics that will be a focus point at the conference, led by members of the Vervaunt team. Here is our commentary piece on tech evaluation, platform decisions and building an ecommerce stack that actually scales, with input from Shamoli Miah.

Most eCommerce brands accumulate technology rather than evaluating it. Apps get added during a migration and never reviewed. Enterprise tools get purchased because a senior stakeholder saw a demo, then sit underutilised because the team doesn't have the capacity to operate them. Decisions that should be grounded in business goals, team capability, and long-term scalability are instead driven by familiarity, cost alone, or whoever shouts loudest.

The result is a tech stack that creates drag rather than leverage. Brands pay for tools they don't fully use, miss integrations that would unlock real efficiency, and discover operational gaps at the worst possible moment - during a migration or a growth push when everything needs to work.

Start with purpose, not products

The most common mistake in tech evaluation is starting with the product. A stakeholder hears about a tool, sees a competitor using it, or gets approached by a vendor, and the conversation immediately becomes about features and pricing. The business goal gets skipped entirely.

Every tech evaluation should begin with a clear articulation of what the business needs to achieve. Not "we need a new reviews platform" but "we need to improve post-purchase engagement and increase repeat rate, and our current reviews setup isn't contributing to that." The distinction matters because the first limits the conversation to a product category, while the second opens it to the actual problem, which might be solved in ways that have nothing to do with a new reviews tool.

When we start a project with a brand, the first step is always understanding business goals across year one, year three, and year five. That context determines everything: which tools are appropriate, how much complexity is justified, and where the real gaps are versus where the team simply hasn't optimised what they already have.

The hierarchy of evaluation: goals, team, ecosystem, then cost

There's a natural order to tech evaluation that most brands either skip or run in reverse. They start with cost and work backwards, which leads to decisions that look efficient on a spreadsheet but create problems in practice.

Business goals first. What is the brand trying to achieve with this technology? Is it a migration to reduce operational costs and simplify? A growth push requiring new markets, higher volume, or more complex customer journeys? The goal shapes everything that follows.

Team capability second. A tool is only as good as the team operating it. If a brand has a one-and-a-half-person eCommerce team, recommending an enterprise-grade marketing platform that requires dedicated resource to configure, maintain, and report from is setting them up to fail. They'll buy it, use 30% of its capability, and conclude the technology doesn't work, when the real issue is a mismatch between product complexity and team capacity.

The honest question isn't "what can this tool do?", it's "what will we actually use, given our team and capacity?" A simpler product that the team can fully operate will almost always outperform an enterprise product that sits 60% idle. Sometimes the fastest route to reducing tech spend is recognising you're already paying for capability you don't use.

Ecosystems fit third. If a brand is running on Shopify, the default position should be Shopify ecosystem products. Not because alternatives don't exist, but because ecosystem-native tools integrate more cleanly, receive more consistent platform updates, and benefit from a larger community solving the same problems. A Shopify-native product will have a roadmap that progresses with the platform. An enterprise product bolted on from outside may technically work, but it introduces integration complexity and ongoing maintenance that a smaller team shouldn't need to manage.

Cost last. Cost matters, obviously. But evaluating it without first understanding goals, team capacity, and ecosystem fit leads to false economies. A cheaper tool that doesn't integrate well costs more in workarounds. An expensive tool that the team can't operate costs more in wasted capability.

Migrations: separating what must happen now from what should happen later

The temptation during a platform migration is to fix everything: new platform, new ERP, new loyalty programme, new integrations, all within a single project timeline.

The reality is that trying to change too many systems simultaneously is how migrations go wrong. Each system change introduces its own complexity, timeline and risk. Stacking them together means one delay affects everything else.

How to structure the sequencing:

The migration itself should be the primary focus. Everything that directly supports it gets included; everything else gets sequenced as a separate project, based on dependency.

ERP changes are a clear example. Moving to Shopify while also implementing a new ERP with middleware means running two functionally separate projects with different timelines, integration partners and internal stakeholders. Trying to run both within a 26-week migration window creates unnecessary risk. The ERP project should run on its own timeline, with clear handoff points.

The same applies to ESP migrations. Moving from Klaviyo to Ometria (or the reverse) during a replatforming adds database migration, customer warming, and email deliverability risk on top of everything else, and deserves its own project.

The framework is straightforward: what must happen within the migration window for the new platform to function? That's in scope. What would be useful to change, but doesn't depend on the migration? That's a separate project with its own timeline and success criteria.

CRM and ESP evaluation: a case study in getting it right

CRM and email marketing are areas where the evaluation variables are particularly instructive.

Consider a brand running three Shopify stores, each with its own Klaviyo instance, looking to consolidate onto Ometria for better reporting and a unified customer view. On paper, the case makes sense. But the evaluation needs to go deeper than a feature comparison.

Team capacity. Ometria is a powerful platform, but it requires internal resource to build and manage marketing strategies within it. Klaviyo is more tightly integrated with Shopify, has a larger Shopify-native roadmap team, and requires less internal resource to operate effectively. The reporting gap that motivated the move might be real, but it doesn't justify adopting a tool the team can't fully use.

Agency support costs. If the brand needs agency support to manage the new platform, that cost needs to be factored in. Ometria support tends to be more expensive than Klaviyo support because the platform is more complex. The "better reporting" benefit needs to be weighed against the full cost, not just the platform licence.

Migration risk. Moving a customer database between ESPs involves warming, deliverability management, and the risk of losing engaged subscribers during the transition. That risk needs to be explicitly accounted for, not treated as a footnote.

Roadmap trajectory. Klaviyo's reporting capabilities are improving. Is the gap that exists today going to exist in 12 months? If the platform is closing the distance on the specific features driving the switch, the disruption of migrating may not be justified.

The point isn't that Ometria is wrong and Klaviyo is right, or vice versa - both are strong platforms for different contexts. The point is that the evaluation needs to account for all of these variables, not just the feature that triggered the conversation.

Managing internal stakeholder pressure

Tech evaluation rarely happens in a vacuum. There are always stakeholders with opinions: the CEO who saw a demo at a conference, the creative director who wants a specific tool, or the finance lead who wants to cut costs. Managing these inputs without letting any single one derail the process is a skill in itself.

The principle we follow is: always say yes to evaluating, but never say yes to implementing without evaluation. When a senior stakeholder arrives with a product they want adopted, the response isn't "no", and it isn't "yes, let's install it." It's "great, let's evaluate it properly and make sure it's the right fit."

That evaluation follows the same framework: goals, team, ecosystem, and cost. If the product passes, it gets adopted with everyone aligned on why. If it doesn't, the recommendation is grounded in evidence rather than opinion, which is much easier to defend.

Structuring accountability:

The brands that manage tech decisions well have clear accountability structures:

• A project sponsor who understands the project in depth

• Monthly steering meetings where all stakeholders are present

• Early finance involvement so budget alignment doesn't become a late-stage blocker.

The creative team deserves a specific mention; they're consistently the group most likely to introduce late-stage changes. Involving them early in discovery, setting clear boundaries on the design phase, and being explicit about what changes are possible within the project timeline turns late-stage rewrites into a collective decision about timeline extension rather than unmanaged scope creep.

Staying ahead of emerging tech without chasing trends

The eCommerce technology landscape moves fast enough that staying current requires deliberate effort. The risk is twofold: falling behind and missing tools that could genuinely help clients, or chasing every new product and losing focus on what actually works.

How to maintain a current view without drowning in it:

Different markets surface different technologies. Working with partners in Sweden, for example, introduced tools and approaches that simply weren't on the radar in the UK market. The US ecosystem surfaces different products again. The broader your market exposure, the broader your reference set. Conferences like Pulse play an important role; the difference between a booth demo and a conversation with someone who's actually implemented the tool is significant. Real implementation stories surface the operational reality that marketing materials don't.

Internally, a weekly standup where each team member shares one thing they've learned, and which clients it could apply to, is low overhead but is beneficial over time. When a trend emerges, a structured evaluation across the full category gives a defensible view rather than a reactive one.

The agnostic evaluation principle

One of the most important disciplines in tech evaluation is genuine agnosticism. It's easy to default to products you know well, have relationships with or have implemented successfully before. Those products might genuinely be the right answer, but the recommendation should come from evaluation, not familiarity.

Every recommendation needs a clear "why" behind it. "We recommend this because we've used it before" isn't good enough.

"We recommend this because it fits your team size, integrates natively with your platform, and solves the specific problem you've described, at a price point that's appropriate for your business" is a recommendation the client can trust and defend internally to their own stakeholders.

What to reassess before committing to new technology

If you're planning a migration, a tech stack review, or evaluating new tools over the next 12 months, these are the areas worth addressing before making decisions:

Evaluation process:

• Define the business goal before evaluating products. What problem are you solving, and what does success look like in 12 months?
• Assess your team's capacity honestly. Can they operate the tool you're considering, or will it sit partially utilised?

• Sequence system changes so the platform migration isn't competing with ERP, ESP, or loyalty programme changes for bandwidth.
• Set clear boundaries on design phases. Late-stage creative revisions are the most common source of timeline slippage.

Cost and capability:

• Audit your current stack for tools you're paying for but underutilising. Right-sizing may save more than switching.

• Factor in total cost of ownership: licence fees, agency support, internal resource and integration maintenance.

• Involve finance early, run monthly steering meetings and when senior stakeholders push for specific tools, commit to evaluation rather than immediate adoption.

• Evaluate trends at category level, remain genuinely agnostic, and build structured knowledge sharing into your team rhythm. One new insight per person per week adds up quickly.

Many of the themes explored here - from making better technology decisions and structuring scalable ecommerce stacks, to managing migrations without unnecessary risk and aligning tools with team capability - will be unpacked in far more depth at the Pulse eCommerce Summit on the 13th and 14th May 2026. Across two days, we’ll bring together senior eCommerce leaders, operators and specialists to share real-world experiences, practical frameworks and honest lessons from scaling brands internationally in a far more complex global landscape. If international growth is on your roadmap for 2026 and beyond, register now to secure your place.