Architecture·November 2024·11 min read

2025 Guide: Selecting the Right Technology for eCommerce Growth

Selecting e-commerce technology by feature checklist produces the wrong platform more often than it produces the right one, because a feature list ranks vendors by what they have, not by what your business actually needs to run. The method that works is requirements first, then constraints, then platform fit, checked in that order and never reversed.

Why feature checklists produce the wrong platform

A list of nine capabilities, scalable infrastructure, AI personalization, integrated ERP and CRM, cybersecurity, analytics, mobile optimization, sustainability tooling, omnichannel sync, AI-driven support, describes almost every commerce platform on the market at some level of maturity. It doesn't tell you which one to pick, because it never asks what your specific catalog, checkout logic, and integration surface actually require.

Every major platform will claim all nine capabilities in its marketing. The differences that actually matter, how deep the personalization engine goes, whether the ERP integration is a real API or a brittle CSV export, show up only once you've defined your own requirements well enough to test a vendor's claim against them.

A three-step method: requirements, constraints, platform fit

Selection done well runs through three stages in a fixed order. Requirements come first: what does the business need this system to do, independent of any vendor's feature set.

Constraints come second: budget, team, compliance, and timeline, the limits that rule specific platforms in or out regardless of how well they'd otherwise fit. Platform fit comes last: given the requirements and constraints already fixed, which architecture model and vendor actually match.

Reversing the order is the single most common selection mistake. Starting from a vendor's feature list means every requirement gets quietly reshaped to match what that vendor already offers, and starting from platform fit before constraints are fixed means falling in love with an architecture the team can't actually operate.

Requirements narrow into constraints, constraints narrow into platform fit, and platform fit resolves into one platform with a sequenced rollout, not a scored feature matrix.

Step 1: Requirements — what the business actually needs to do

Catalog and checkout complexity

A catalog of 200 configurable SKUs with simple shipping rules has almost nothing in common, technically, with a catalog of 50,000 variants across multiple brands with tiered B2B pricing. The first can run comfortably on a platform's default checkout. The second needs to know, concretely, whether the platform's checkout can express its pricing and eligibility rules natively or requires custom logic injected at a defined extension point.

Integration requirements

List every system of record the storefront has to stay in sync with, ERP for inventory and financials, CRM for customer service, a WMS for fulfillment, before evaluating any platform. A platform with an elegant storefront and a shallow, rate-limited API for your specific ERP is a worse fit than a less polished platform with a documented, first-party connector for that exact system.

Traffic and scale profile

Peak-to-average traffic ratio matters more than raw traffic volume. A business with steady, predictable traffic has different infrastructure requirements than one with a single flash-sale day driving twenty times normal load, and the second case rules out platforms whose scaling model depends on manual capacity planning ahead of the spike.

A requirement that can't be stated without naming a specific vendor isn't a requirement yet. It's someone's early conclusion dressed up as a spec.

Step 2: Constraints — the limits that rule platforms out regardless of fit

Budget shapes architecture more than features do

Composable, API-first architectures give a business more control over each piece of the stack, but that control comes with more vendor contracts to manage and more infrastructure to operate. A team's budget has to cover licensing and the operational cost of running a distributed architecture, before composable becomes the right constraint-satisfying answer rather than an aspirational one.

PCI DSS is a hard constraint, not a feature to compare

Any platform handling payment card data has to meet PCI DSS, and the current version of the standard, v4.0.1, requires multi-factor authentication for access to the cardholder data environment as a baseline, not an optional add-on (PCI Security Standards Council — PCI DSS). A platform that pushes PCI scope onto the merchant's own infrastructure, rather than handling it within a certified payment flow, is a materially different operational commitment than one that doesn't, regardless of how the two compare on any other feature.

Team size and operational maturity

A composable, multi-vendor architecture needs a team capable of running distributed tracing, per-service CI/CD, and contract testing across services from day one. A team of three engineers evaluating a composable stack against a monolithic platform isn't comparing features, it's comparing whether the team can operationally support the architecture at all.

Step 3: Platform fit — matching architecture models to requirements

With requirements and constraints fixed, platform fit becomes a narrower, more mechanical comparison. Four broad architecture archetypes cover most of the real decision space.

Archetype	Example	Best fit when	Poor fit when
Monolithic SaaS	Shopify, BigCommerce	Team is small, catalog is standard, speed to launch matters most	A specific capability (search, B2B pricing) needs deeper customization than the platform's extension points allow
Composable / MACH	commercetools	Distinct requirements at specific seams justify running several best-of-breed services independently	Team lacks per-service CI/CD, distributed tracing, and contract-testing maturity already in place
Headless enterprise suite	Adobe Commerce	Large catalog and complex B2B logic need a mature commerce engine, decoupled front end optional	Budget and timeline don't support enterprise-suite implementation and licensing cost
Open-source self-hosted	Self-hosted platforms on your own infrastructure	Team wants full control over infrastructure and no vendor licensing cost	Team doesn't want to own security patching, scaling, and uptime directly

commercetools describes its own architecture as a centralized foundation for core commerce data, customers, products, pricing, and inventory, that teams assemble alongside other MACH-aligned services rather than adopt as a single monolithic suite (commercetools — Implementation Guide: Architecture). Adobe Commerce's own documentation is explicit that its architecture isn't all-or-nothing: a merchant can run headless with REST and GraphQL APIs, or run the coupled storefront, depending on which mix actually matches their requirements (Adobe Commerce — Headless Architecture). Neither vendor's own documentation claims to be the universally correct choice, which is itself a useful signal that architecture fit, not vendor quality, is the deciding factor.

The extensibility question: platform extension points vs. custom code

Whichever archetype fits, the next question is how the platform lets you customize without forking it. Shopify Functions inject custom business logic, discount rules, shipping eligibility, payment method availability, directly into checkout and order processing as sandboxed functions the platform invokes at the right point (Shopify.dev — Functions). Checkout UI extensions register at defined extension points and run isolated from the checkout page's sensitive data (Shopify.dev — Apps in checkout).

This is the same core-versus-context question covered in depth in our piece on bespoke application cost: a platform's extension points should absorb every requirement that isn't genuinely differentiating, leaving bespoke development for the requirements that actually are.

Performance is a selection criterion, not a post-launch fix

Core Web Vitals, Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift, are Google's own measured thresholds for real-world loading, responsiveness, and visual stability, and a site needs 75% of visits to meet the "good" threshold on each metric to be considered passing (web.dev — Web Vitals). Google's Search Central documentation ties these same metrics directly to how a page's experience is evaluated (Google Search Central — Core Web Vitals).

Platform selection should include checking whether the platform's default theme and checkout can plausibly hit those thresholds at your catalog's scale, not assuming performance is a problem to solve after launch. A platform architecture that makes every additional storefront customization cost render time is a performance liability baked into the selection, not a bug to fix later.

Analytics and data ownership

Google Analytics 4's Data API, Admin API, and Measurement Protocol give a business programmatic access to its own event data, rather than locking reporting inside a dashboard (Google for Developers — Google Analytics). Whichever platform you select, confirm event data can be exported and queried on your own terms, because a platform that only exposes analytics through its own locked dashboard limits every future decision that depends on that data.

Security and compliance as a selection filter, not a checkbox

The PCI Security Standards Council's document library lays out the full framework of specifications and supporting resources a business is expected to meet for handling cardholder data, not a single checkbox item (PCI Security Standards Council — Document Library). Evaluate how much of that framework a platform absorbs on your behalf, hosted, PCI-compliant checkout, versus how much compliance burden shifts onto your own infrastructure if you self-host any part of the payment flow.

A platform that quietly shifts PCI scope onto your infrastructure isn't cheaper. It's the same compliance cost, moved from the vendor's balance sheet to yours.

Exit cost is part of platform fit, not an afterthought

Every platform choice is also an exit-cost decision, whether or not it gets evaluated as one. A monolithic SaaS platform typically owns your product catalog, order history, and customer records in its own schema, which means switching later means a full data migration and, often, rebuilding checkout logic against a different platform's extension model from scratch.

A composable architecture spreads that same lock-in across several vendors instead of concentrating it in one, which sounds like an improvement until you count the exit cost of each individual contract separately. Five vendor relationships to unwind is not obviously cheaper than one, it's a different shape of the same problem, and platform fit should weigh that honestly rather than treating composability as lock-in-free by default.

What to check before signing, not after

Confirm data export formats and API access are available on your current plan, not gated behind an enterprise tier you'd only discover you needed during a migration. Confirm the contract's notice period and data-retention terms after cancellation. Neither question shows up on a feature comparison chart, and both determine how expensive it is to leave if the platform fit turns out to be wrong.

Worked example: a mid-size DTC brand with wholesale ambitions

A direct-to-consumer brand doing $8M in online revenue, with a 400-SKU catalog and a new plan to sell wholesale to retail partners, runs the funnel like this. Requirements: standard D2C checkout plus a separate wholesale pricing and minimum-order-quantity logic the current platform's checkout can't express natively. Constraints: a two-person engineering team, a fixed nine-month budget, and PCI scope the team wants the platform to absorb entirely.

Platform fit, given those constraints, rules out composable architecture outright, the team can't operate a multi-vendor distributed stack, and rules out a full headless enterprise suite on timeline and budget. The fit is a monolithic SaaS platform with a checkout extension point capable of expressing the wholesale pricing logic as a sandboxed function, keeping the two-person team inside the platform's PCI-compliant checkout rather than building custom payment handling.

Sequencing the selection and rollout

Write requirements as vendor-agnostic statements: what the system must do, not which platform should do it
Fix constraints, budget, team capacity, compliance scope, and timeline, before evaluating a single vendor
Score two to three platforms against requirements and constraints together, not against a generic feature list
Pilot the highest-scoring platform's extension points against your hardest real requirement before committing, not against a vendor demo
Migrate using a phased, façade-based cutover rather than a single go-live date, the same strangler fig approach that applies to any legacy migration

Common selection mistakes

Starting from a feature checklist instead of vendor-agnostic requirements, which quietly biases the whole process toward whichever vendor's marketing you read first
Choosing composable architecture before confirming the team has the operational maturity, per-service CI/CD, tracing, contract testing, to run it
Treating PCI compliance as a line item instead of a constraint that changes which platforms are viable at all
Deferring performance and Core Web Vitals evaluation until after launch, when the platform's architecture already set the ceiling
Picking a platform based on its demo instead of piloting the platform's actual extension points against your hardest real requirement

FAQ

What's the single biggest mistake in e-commerce platform selection?

Starting from a feature comparison instead of vendor-agnostic requirements. Every platform's marketing claims the same nine or ten capabilities; the requirements process is what reveals which claims actually hold up for your specific catalog and integrations.

Is composable architecture always the more future-proof choice?

No. Composable architecture is the right choice only when a team already has, or is prepared to build, the operational maturity to run several independently deployed services. Without that maturity, a monolithic platform's built-in tools deliver more real change velocity than an under-resourced composable stack.

How early should Core Web Vitals be part of the selection process?

Before selection, not after launch. The platform's rendering architecture sets a performance ceiling that a launch-time optimization pass can't fully undo.

Does PCI compliance really rule platforms in or out?

Yes, in practice. A platform that keeps PCI scope inside its own certified checkout is a fundamentally different operational commitment than one that pushes cardholder-data handling onto your infrastructure.

Should a small team ever consider a headless enterprise suite?

Rarely. Headless enterprise suites are built for catalog and B2B complexity that justifies their implementation cost and timeline; a small team without that complexity is paying for capability it won't use.

How does platform extensibility fit into the selection decision?

It determines whether your hardest real requirement can be met through a sandboxed extension point or requires bespoke development the team has to maintain indefinitely, a decision covered in more depth in our piece on bespoke application cost.

References

From the Destm engineering archive. For current work on this topic, start at Solutions or the blog.