How to Evaluate an Ecommerce Platform in 2026: 27 Criteria That Matter

Why feature-count comparisons pick the wrong ecommerce platform is the question this article answers before the series names a single vendor. Feature-count tables are why most ecommerce platform comparisons online look interchangeable: they tally boxes ticked instead of measuring what breaks under catalogue growth, integration load, or an upgrade six months in. This article replaces that with a fixed matrix of 27 scored criteria and two weighted 0-10 rubrics — modernity and AI/agent readiness — checked against an evidence policy that requires four of six proof layers with a dated confidence label per claim. This edition is pinned to schema.org 30.0 (opens in a new tab) (released 2026-03-19), Google’s generative-AI optimisation guide (opens in a new tab) (2026-05-15 edition), and the Model Context Protocol spec (opens in a new tab) current as of 2026-07-27.

Why feature-count comparisons pick the wrong ecommerce platform

A feature-count table can tell you whether a platform has multi-currency support. It can’t tell you whether that feature still works once your catalogue crosses 50,000 SKUs, whether your checkout customisation survives the next major upgrade, or who owns the pager when search relevance degrades. Catalogue growth, integration load, checkout customisation, search relevance, upgrade pain and operational ownership are the variables that decide whether a platform survives past its first year — a checklist treats every one of them as an afterthought.

Google’s own quality framework rewards the opposite habit. E-E-A-T — Experience, Expertise, Authoritativeness, Trustworthiness — is Google’s framework for judging content quality (opens in a new tab), and Google states trust matters most of the four. In December 2022, Google added the Experience component (opens in a new tab) to its Search Quality Rater Guidelines specifically to check whether content came from actual hands-on use of a product, not just research about one.

Google’s people-first content guidance asks whether an article offers original analysis and first-hand depth, rather than restating what other pages already say, and it names high-volume automated production as a red flag. A framework built on the same operational evidence Google rewards isn’t a coincidence of search strategy — it’s the same discipline applied twice.

This article is that framework, and the fixed anchor for the rest of the series. Every platform review in the 16-week calendar scores against the same 27 criteria and the same two weighted rubrics published here, instead of inventing new ones per article. What follows: the full 27-criteria matrix, the exact weights behind both 0-10 rubrics, and the disclosure policy that keeps every claim in this series checkable.

You should now see: why this framework exists, and can name the three artefacts — matrix, rubrics, disclosure policy — the rest of the article hands you.

The 27 criteria in the ecommerce platform evaluation matrix

The master matrix used throughout this series scores 27 criteria, grouped into four clusters. Score each cluster on its own terms — a platform can lead on product surface and lag badly on operations, and folding both into one number would bury that gap.

The commercial cluster (5 fields) covers what a buyer checks before requesting a demo: primary category, licence/model, software price, realistic TCO drivers, and marketing strategy. The technical cluster (9 fields, the largest) covers the engineering surface: technology, architecture, API maturity, headless readiness, modernity score, AI/agent readiness, MCP/tool support, events and automation, and extension ecosystem.

The product-surface cluster (7 fields) covers what ships versus what needs assembly: storefront included, admin included, multi-store/channels, multi-vendor, B2B, international commerce, and search/catalogue. The operational cluster (6 fields) covers who owns the pager: scalability model, hosting/DevOps burden, upgrade risk, security ownership, developer availability, and time to first store.

Five more fields sit outside the 27 scored criteria on purpose: best-fit customer, core problem solved, strongest advantage, failure boundary, and market gap. These describe a platform in prose, and forcing them into a 0-10 score would manufacture false precision. Two disclosure fields also sit outside the 27 — evidence confidence and last verified — because they record how trustworthy each scored value is, not what’s being scored.

Copy the shape below into your own spreadsheet or YAML file and fill in one row per platform under evaluation. The values here are illustrative, for a hypothetical platform, not a real vendor’s scores:

platform: "ExampleCommerce"

# Commercial cluster (5)
primaryCategory: "headless-engine"
licenceModel: "open source"
softwarePrice: "free core; hosting and support add cost"
tcoDrivers: ["hosting", "search infrastructure", "paid extensions", "upgrade labour"]
marketingStrategy: "developer-led open source with a hosted cloud tier"

# Technical cluster (9)
technology: "Node.js, GraphQL, PostgreSQL"
architecture: "API-first, headless"
apiMaturity: "REST and GraphQL, versioned, OpenAPI schema published"
headlessReadiness: "native"
modernityScore: 7.5
aiAgentReadiness: 6
mcpToolSupport: "community"
eventsAutomation: "webhooks with signatures and retries"
extensionEcosystem: "plugin SDK, no core patching required"

# Product-surface cluster (7)
storefrontIncluded: "reference storefront, not production-ready"
adminIncluded: "yes"
multiStoreChannels: "native"
multiVendor: "custom"
b2b: "partial, quote workflows need a plugin"
internationalCommerce: "multi-currency native, tax via extension"
searchCatalogue: "built-in, Elasticsearch supported"

# Operational cluster (6)
scalabilityModel: "horizontal, stateless app servers"
hostingDevopsBurden: "medium, self-hosted or vendor cloud"
upgradeRisk: "low, semantic versioning with published migration scripts"
securityOwnership: "self-hosted: yours; cloud tier: shared"
developerAvailability: "moderate, smaller hiring pool than PHP or Java"
timeToFirstStore: "1-2 weeks with an integrator"

flowchart TD
    subgraph Commercial["Commercial - 5 fields"]
        C1[primary category / licence / price]
        C2[TCO drivers / marketing strategy]
    end
    subgraph Technical["Technical - 9 fields"]
        T1[technology / architecture]
        T2[API maturity / headless readiness]
        T3[modernity score / AI-agent readiness]
        T4[MCP support / events / extensions]
    end
    subgraph ProductSurface["Product surface - 7 fields"]
        P1[storefront / admin included]
        P2[multi-store / multi-vendor / B2B]
        P3[international / search-catalogue]
    end
    subgraph Operational["Operational - 6 fields"]
        O1[scalability / hosting burden]
        O2[upgrade risk / security ownership]
        O3[developer availability / time to first store]
    end
    Commercial --> Matrix[27-criteria scored matrix]
    Technical --> Matrix
    ProductSurface --> Matrix
    Operational --> Matrix
    Matrix -.excluded.-> Narrative["Narrative fields, not scored:<br/>best-fit customer, core problem,<br/>strongest advantage, failure boundary,<br/>market gap"]
    Matrix -.excluded.-> Disclosure["Disclosure fields, not scored:<br/>evidence confidence, last verified"]

You should now see: the complete 27-item checklist, grouped into four clusters, ready to copy into your own comparison spreadsheet.

How the modernity score is calculated, with its exact weights

Modernity is scored, not eyeballed. The table below is this series’ exact rubric — seven components, each capped at its own weight, summing to a 0-10 scale used identically in every platform review.

Score each row against its own cap — API-first boundaries scores anywhere from 0 to 2, extension model from 0 to 1.5 — then add all seven for the final number. A platform doesn’t need a perfect score on every row to score well overall; it needs the weight distributed across rows that hold up under actual testing.

The explicit rule that keeps this rubric honest: a new JavaScript stack is not automatically more modern than a mature PHP, Ruby, Python or .NET platform. Score architecture discipline, tooling, and maintenance — not which language happens to be fashionable this year. A ten-year-old codebase with clean API boundaries, a real CI pipeline, and disciplined releases outscores a two-year-old framework with none of those.

That’s the point of the rubric. Modernity measures whether a team can operate and extend the platform safely for years, not how new the marketing page looks. A homepage redesign has no row in this table.

You should now see: how to score any platform’s modernity out of 10 using the same seven weighted components this series uses in every review.

How the AI and agent-readiness score is calculated, with its exact weights

AI/agent readiness gets the identical treatment: seven weighted components, each scored against its own cap, summing to 0-10.

MCP — the Model Context Protocol — is the term doing the most work in that last row, and it’s worth defining precisely rather than treating as a buzzword. MCP is an open standard (opens in a new tab) for connecting AI applications to external data sources, tools and workflows. It’s supported across independent clients — Claude, ChatGPT, VS Code, Cursor — rather than being one vendor’s feature, which is why “official MCP support” is a checkable claim rather than a marketing flourish tied to any single AI product.

The explicit rule here mirrors the modernity rubric’s: a platform is not AI-ready merely because a chatbot widget or an “AI product recommendations” feature sits on the marketing page. Score strictly against the seven components above — a recommendations widget satisfies none of them on its own.

Notice the rubric deliberately re-tests API completeness, which already has a row in the modernity table. That isn’t duplication. An API can be complete enough for a human admin clicking through a UI and still unsafe to hand to an autonomous agent with no permission scoping and no audit trail — the two rubrics ask different questions of the same surface.

You should now see: how to score any platform’s AI/agent readiness out of 10, and how to reject an “AI-ready” marketing claim that isn’t backed by the seven components above.

Why AI-readiness gets its own score instead of folding into modernity

A single blended score would hide the case that matters most: a platform can score high on modernity — clean API-first architecture, real CI, disciplined releases — while its AI/agent readiness is capped by missing granular write permissions or no official MCP tooling. Average those two numbers and a buyer planning an agent-driven workflow never sees the gap that would have stopped the project.

The reverse happens too. A platform can bolt an MCP server or an agent SDK onto an otherwise dated core — an ageing framework, no real extension model, thin CI — and a single merged number would overstate what that platform can support long-term.

flowchart LR
    subgraph PlatformA["Platform A: clean API core, no MCP"]
        A1["Modernity: 8.5/10"]
        A2["AI/agent readiness: 3/10"]
    end
    subgraph PlatformB["Platform B: bolted-on agent SDK"]
        B1["Modernity: 4/10"]
        B2["AI/agent readiness: 7.5/10"]
    end
    A1 --> ABlend["Blended score: 5.75"]
    A2 --> ABlend
    B1 --> BBlend["Blended score: 5.75"]
    B2 --> BBlend
    ABlend -.same number, opposite risk.- BBlend

Read the two scores as answers to two different questions, for two different buyers. Modernity asks whether the platform’s architecture will support your team for the next several years. AI/agent readiness asks whether the platform can safely expose commerce operations to an agent today. A CTO planning a five-year platform bet weights the first; an engineer wiring an MCP server into a checkout flow this quarter weights the second.

Both rubrics share the same 0-10 scale and the same point-cap weighting method, so the two numbers stay directly comparable across every platform this series reviews — you can put them side by side without normalising anything.

You should now see: which of the two scores to weight more heavily, depending on whether you’re evaluating long-term architecture fit or near-term agent integration.

The evidence and disclosure policy behind every claim in this series

Every platform review in this series needs evidence from at least four of six proof layers before a matrix row gets filled in: primary product proof (docs, licence, pricing, release notes), hands-on engineering proof (install notes, API calls, screenshots), adoption/social proof, news proof, developer proof (issues, maintainer responses), and merchant/community proof. Four sources about the same claim don’t count — four different layers do.

Every review carries a required evidence box: version tested and date, test environment, test catalogue size, tasks tested, official sources, community sample, per-claim confidence (high, medium or low), and limits — what wasn’t tested. A reader can check that box against a review’s actual claims before trusting its score.

flowchart TD
    Claim["A claim about a platform,<br/>especially a negative one"] --> Check{"Checked directly -<br/>docs, repo search,<br/>marketplace search,<br/>install test?"}
    Check -- No --> NotVerified["Write: 'not verified'<br/>never assert as fact"]
    Check -- Yes --> Layers{"Evidence spans<br/>at least 4 of 6<br/>proof layers?"}
    Layers -- No --> Gather["Gather more layers<br/>before scoring this claim"]
    Layers -- Yes --> Record["Record method, date,<br/>confidence (high/medium/low)<br/>Publish with the claim"]

The proof-of-lacuna rule covers negative claims specifically, because a claim like “no official MCP support” is the easiest kind of statement to get wrong. It must record where it was checked, the method, the date and the confidence level. An unchecked gap gets written as “not verified” — never asserted as fact.

That distinction — absence of evidence versus evidence of absence — means a vendor shipping the feature next month becomes a dated changelog entry in this series, not a retraction. Where an article in this series recommends svelte-commerce as a pairing storefront, it discloses that this is the author’s own open-source project and shows only the wiring actually demonstrated, not a hypothetical integration.

You should now see: whether any given platform review in this series meets its own evidence bar before you trust its score.

What the 27-criteria evaluation framework does not cover

This matrix does not produce a single ranked winner across platforms. The 27 scores and both rubrics are comparative inputs; a “best platform” verdict still depends on your specific TCO drivers, your team’s skill, and how much of a platform’s failure boundary you can tolerate. Two platforms scoring 7.5 on modernity can be the right and wrong choice for the same buyer, depending on what the other 25 fields say.

The framework publishes no absolute scalability ranking without a stated workload, catalogue size and infrastructure specification attached to it. An unqualified claim — “handles millions of SKUs” with no test conditions named — gets dropped rather than published, because a reader can’t reproduce a number that isn’t attached to a workload.

The 27 criteria and both rubrics reflect this series’ stated priorities: operational ownership and AI/agent readiness. They are not a universal industry standard. A reader who weights differently — toward pure page-speed, say, or accessibility compliance — should reweight the rubric for their own use, rather than treat these numbers as objective.

This edition is pinned to specific versions: schema.org 30.0, released 2026-03-19; Google’s generative-AI optimisation guide, 2026-05-15 edition; and the MCP spec current as of 2026-07-27. A materially changed spec or guideline is grounds to revisit these weights, not a reason to keep citing this edition past its shelf life.

You should now see: exactly what claims this framework does and doesn’t license, and which version edition its weights are pinned to.

Run this five-question proof-of-concept checklist before shortlisting a platform

Run these five questions against your own trial or sandbox before a platform reaches your shortlist. A vendor demo answers none of them for you.

1. Install or trial the platform yourself and record install time and every required service — the same discipline this series’ installation sub-series applies to every open-source platform in its matrix: real commands, real output, no behaviour inferred from documentation alone.
2. Pull the documented API surface and count coverage against nine areas: catalogue, pricing, inventory, carts, checkout, orders, customers, refunds and configuration. Those nine areas feed both weighted rubrics directly — gaps here cap the modernity and AI-readiness scores before you’ve scored anything else.
3. Score the platform’s modernity and AI/agent readiness yourself, using the two rubrics from this article, rather than accepting the vendor’s own claim. An “AI-ready” badge is not a substitute for checking the seven components in each table.
4. Check for official MCP or agent tooling directly in the documentation or repository — not a marketing page — and record the check date and method, per the disclosure policy above.
5. Request an itemised quote, or read the published licence terms line by line, and map every line item back to a TCO driver in the matrix before comparing platforms on price alone.

Leave the trial with five written answers, not five verbal impressions from a sales call. That’s the same evidence bar this series applies before it publishes any platform review — the framework only works if you hold your own shortlist to it.

You should now see: five written answers from your own trial or sandbox — the same evidence bar this series applies before publishing any platform review.

Limitations

This framework scores platforms on operational and AI/agent-readiness criteria. It does not score page-speed, accessibility compliance, or payment-provider breadth, and a reader prioritising those should reweight the rubric rather than borrow these numbers directly.

It does not resolve pricing for quote-based platforms. Commercial-cluster fields like software price stay “quote-based” until you request one, and this article does not estimate what your quote will be.

The 27-criteria matrix and both rubrics are pinned to this edition’s stated versions. A materially updated MCP spec, a new schema.org release, or a revised Google ranking guideline is grounds to revisit the weights in a future edition — this article does not track that drift on its own.