Choose an Ecommerce Platform and Stack

By Sarthak Arora · From the Ecommerce Growth collection · Updated July 2026

This prompt turns a pile of vendor pitches into a defensible stack decision. You feed it your actual business requirements and it maps them to the layer of the stack each requirement touches, flags where a platform is structured poorly for what you need, and returns a recommended platform plus the apps, martech, fulfillment, and accounting choices that follow from it. The output is a decision document you can defend to a founder or a board, not a popularity contest.

When to use this

You are choosing a platform or moving your ecommerce store to a new one and want the decision driven by requirements, not by what everyone else runs.
Someone is pushing you toward a headless build, more variants, or a shiny app and you need to pressure test whether your requirements actually justify it.
You are assembling the surrounding stack (page building, martech integrations, SMS, customer service, fulfillment, accounting) and want each choice to trace back to a real need.

Fill in the variables

BUSINESS_MODEL

The shape of the business, for example "single brand DTC supplements, subscription heavy" or "B2B distributor with negotiated account pricing."

SPECIAL_REQUIREMENTS

The non negotiables that break default platforms, for example "customers pre pay three months and choose box contents each cycle" or "content first blog on the main domain."

{{CATALOG_SIZE}} and {{VARIANTS_PER_PRODUCT}}: real numbers, since a variant count above 100 or a catalog in the thousands changes both platform and page building choices.

CHANNELS

Every place you sell, since multiple marketplaces plus retail is what pushes you toward feed tools and eventually an ERP.

{{TEAM}} and {{PRIORITIES}}: whether you can maintain lower layers, and the ranked tradeoff between stability, design freedom, speed, maintenance, and cost.

The prompt

Full method. Works on any model.

You are a senior ecommerce architect. You map requirements to architecture, refuse to bend a platform into a job it is structured poorly to do, and treat "headless," "faster," and "more secure" as claims to verify, never reasons to buy.

CONTEXT
→ Business: {{BUSINESS_MODEL}}; Revenue: {{REVENUE}}; Channels: {{CHANNELS}}
→ Catalog: {{CATALOG_SIZE}} products, {{VARIANTS_PER_PRODUCT}} variants per product at most
→ Special requirements: {{SPECIAL_REQUIREMENTS}} (subscription cadence, account pricing, deep customization, blog on the main domain, layered navigation, custom login durations, regulated products)
→ Team: {{TEAM}}; Current stack and pain: {{CURRENT_STACK}}; Priorities ranked: {{PRIORITIES}}

If any core input is missing or vague, ask me clarifying questions one at a time, up to five, and wait for my answer before asking the next. Do not produce a recommendation until every input that could flip the platform choice is pinned down. Never guess at one.

METHOD

1. Map each requirement to the four layer model: user interface (front end), application (cart, checkout, logic), database (records), server (hosting, OS). Name the layer each touches and whether it needs direct control or only API access. More control means more power and more maintenance; less means more stability. State the tradeoff the priorities imply.

2. Select the platform at the intersection of requirements and platform limits. Default to SaaS unless the brand is primarily a technology company.
   → Shopify is the SaaS default. Move OFF it for: subscription logic controlling pre payment, cadence, and contents at once; account level or negotiated pricing; deep customization at purchase beyond the API; a content first blog on the main domain; robust layered navigation; a variant count per product above its cap (long quoted at 100; confirm the current number); or custom login durations.
   → BigCommerce for SaaS needing higher API rate limits, a higher variant ceiling (long quoted at 600; confirm the current number), friendlier third party checkouts, or regulated products such as CBD.
   → Adobe Commerce or Magento (open source, all four layers editable) for strong B2B pricing, large catalogs, very high SKU counts, and heavy customization; cost is high maintenance since every customization is re validated on each patch.
   → Reject WooCommerce for a serious business: commerce on WordPress forces you to patch both stacks the moment a vulnerability is disclosed, a permanent security chase where patches can break your code.
   → Name the single requirement that decides the platform. Rule: never bend a platform to do something it is structured poorly to do.

3. Decide headless on requirement, never hype. Headless runs content and commerce on separate systems; it reliably raises maintenance cost, and speed, flexibility, and security gains are implementation dependent, not guaranteed. Recommend it ONLY when a non negotiable requirement cannot be met by any single system, the domain is overwhelmingly content with minimal commerce, or a heavily used commerce engine already exists and just needs a front end.

4. Choose the page building approach, most native to least: native theme sections (best compatibility and speed, least layout freedom); an in store builder (design freedom on domain with live data, at a speed cost); an external landing builder (most freedom for paid landing pages, but off the main domain); custom code with a metafield driven theme (best for templated data at scale). Rule: each step off the native theme buys design freedom but costs compatibility, load speed, and templating ease.

5. Build the surrounding stack from requirements, not defaults.
   → Apps fill native gaps but share the platform's constraints, so evaluate each against those limits; test price by real time per visitor routing judged on profit per customer, not conversion alone.
   → Martech follows a basic versus advanced rule: native tracking works well, but native product and order syncs are too basic and need a feed tool once you apply rules or handle a large or fast changing catalog.
   → Fulfillment and accounting escalate with complexity: an order management system bridges store and carrier, a warehouse management system adds rate shopping, routing, replenishment, and kitting, and an ERP replaces standalone accounting only when multiple channels demand one system of record, driven by operational complexity rather than revenue alone.

OUTPUT FORMAT
1. Requirement to layer map: each requirement, its layer, direct control or API access.
2. Platform recommendation: the chosen platform, the single deciding requirement, and the runner up you rejected and why.
3. Headless verdict: yes or no, with the requirement that justifies it or the reason it is unjustified here.
4. Stack build sheet: page approach, apps for native gaps, martech marked basic or advanced, and fulfillment and accounting, each with a one line rationale tied to a requirement.
5. Watch outs: the top three ways this stack could fail and how to prevent each.
6. Fact check list: every platform limit, variant cap, API rate limit, pricing claim, and app capability the recommendation depends on, one line each, marked "verify against current vendor documentation before committing." State which ones would change the recommendation if they turn out different.

SELF CHECK
→ Never present a cap, rate limit, or price as current fact; these change, so every one you rely on must appear in the fact check list.
→ Confirm every choice traces to a specific requirement, not to what is popular; cut any that does not.
→ Failure modes to avoid: bending a platform into a job it handles poorly; treating headless as an automatic speed or security win; buying an app capped by the same constraint you are trying to escape; buying an ERP before complexity requires one.

For the most capable models. Goal and quality bar up front.

You are a senior ecommerce architect who maps requirements to architecture and never bends a platform into a job it is structured poorly to do.

GOAL: Produce a defensible stack decision I could hand to a founder or board. Your first line is the verdict: the recommended platform and the single requirement that decides it. Everything after supports that verdict.

CONTEXT
→ Business: {{BUSINESS_MODEL}}; Revenue: {{REVENUE}}; Channels: {{CHANNELS}}
→ Catalog: {{CATALOG_SIZE}} products, {{VARIANTS_PER_PRODUCT}} variants per product at most
→ Special requirements: {{SPECIAL_REQUIREMENTS}} (subscription cadence, account pricing, deep customization, blog on the main domain, layered navigation, custom login durations, regulated products)
→ Team: {{TEAM}}; Current stack and pain: {{CURRENT_STACK}}; Priorities ranked: {{PRIORITIES}}

PRINCIPLES (load bearing rules of the method)
→ Map each requirement to the layer it touches (front end, application, database, server) and whether it needs direct control or only API access. More control means more power and more maintenance; state the tradeoff the priorities imply.
→ Default to SaaS unless the brand is primarily a technology company. Move off Shopify for pre payment subscription logic, account or negotiated pricing, deep customization beyond the API, a content first blog on the main domain, robust layered navigation, a variant count above its cap, or custom login durations. Consider BigCommerce for higher API limits, a higher variant ceiling, friendlier third party checkouts, or regulated products; Adobe Commerce or Magento for heavy B2B pricing, large catalogs, and deep customization at high maintenance cost. Reject WooCommerce for a serious business.
→ Recommend headless only when a non negotiable requirement cannot be met by any single system, the domain is overwhelmingly content, or a heavy commerce engine already exists and just needs a front end. It reliably raises maintenance; speed and security gains are not guaranteed.
→ Choose page building from most native to least, trading design freedom for compatibility and load speed. Build the surrounding stack (apps, martech, fulfillment, accounting) from requirements: apps share the platform's constraints, native product and order syncs need a feed tool once rules or a large catalog apply, and an ERP arrives only when operational complexity demands one system of record.

QUALITY BAR (what excellent output must satisfy)
→ Every choice traces to a specific named requirement, and at least one option is rejected with a reason.
→ The platform hinges on one decisive requirement, not a feature tally or popularity.
→ The headless verdict is a clear yes or no tied to one of the three legitimate triggers.
→ The answer ends with a fact check list naming every variant cap, API rate limit, price, and app capability the recommendation leans on, each marked "verify against current vendor documentation before committing," and calls out which ones would flip the decision if they turn out different.
→ Watch outs name concrete failure modes, not generic caution.

BOUNDARIES
→ Do not invent data, caps, rate limits, or prices; present none as current fact.
→ Do not pad with generic advice or choices that do not trace to a requirement.
→ If a core input that could flip the platform choice is missing, ask one focused question and wait, rather than guessing.

Five lines. Speed over rigor.

Act as a senior ecommerce architect. Given {{BUSINESS_MODEL}}, {{SPECIAL_REQUIREMENTS}}, {{CATALOG_SIZE}} and {{VARIANTS_PER_PRODUCT}}, recommend a commerce platform and the apps, martech, and fulfillment that follow.
Default to SaaS; move off it only when a specific requirement forces it.
Lead with the platform and the single requirement that decides it, then name one option you rejected and why.
Every choice must trace to a named requirement, and any variant cap, API limit, or price must be flagged "verify against current vendor documentation."
If a requirement that could flip the choice is missing, ask one question first.

Want all 120 prompts in one workspace?

Every prompt in this library, organized by task. Free.

What good output looks like

Every recommendation names the specific requirement that drives it, and at least one option is rejected with a reason.
The platform choice hinges on a single decisive requirement, not on a feature tally or on what is popular.

Show 4 more quality checks

The headless verdict is a clear yes or no tied to one of the three legitimate triggers, and calls out hype where the requirement is absent.
The answer ends with a fact check list naming every variant cap, API limit, price, and app capability the recommendation leans on, each flagged for verification against current vendor documentation, with the ones that could flip the decision called out.
If a core input was missing, the model asked for it one question at a time before recommending, rather than guessing.
The watch outs section names concrete failure modes (a platform bent past its architecture, an app capped by the same constraint, tracking that silently drops on a theme swap), not generic caution.

Related prompts

Optimize Product Discovery
Once the platform is chosen, tune navigation, search, and filtering so shoppers actually find products.
Design Offers That Raise Order Value
Put the upsell, gift, and bundle apps from your stack to work lifting average order value.
Plan a Peak Promotion End to End
Stress test the stack you chose against the traffic and fulfillment load of a peak sales event.

Free to use and share. If you republish a prompt, link back to this library.

Choose an Ecommerce Platform and Stack

When to use this

You are choosing a platform or moving your ecommerce store to a new one and want the decision driven by requirements, not by what everyone else runs.

Someone is pushing you toward a headless build, more variants, or a shiny app and you need to pressure test whether your requirements actually justify it.

You are assembling the surrounding stack (page building, martech integrations, SMS, customer service, fulfillment, accounting) and want each choice to trace back to a real need.

Fill in the variables

BUSINESS_MODEL

The shape of the business, for example "single brand DTC supplements, subscription heavy" or "B2B distributor with negotiated account pricing."

SPECIAL_REQUIREMENTS

The non negotiables that break default platforms, for example "customers pre pay three months and choose box contents each cycle" or "content first blog on the main domain."

{{CATALOG_SIZE}} and {{VARIANTS_PER_PRODUCT}}: real numbers, since a variant count above 100 or a catalog in the thousands changes both platform and page building choices.

CHANNELS

Every place you sell, since multiple marketplaces plus retail is what pushes you toward feed tools and eventually an ERP.

{{TEAM}} and {{PRIORITIES}}: whether you can maintain lower layers, and the ranked tradeoff between stability, design freedom, speed, maintenance, and cost.

The prompt

Full method. Works on any model.

You are a senior ecommerce architect. You map requirements to architecture, refuse to bend a platform into a job it is structured poorly to do, and treat "headless," "faster," and "more secure" as claims to verify, never reasons to buy.

CONTEXT
→ Business: {{BUSINESS_MODEL}}; Revenue: {{REVENUE}}; Channels: {{CHANNELS}}
→ Catalog: {{CATALOG_SIZE}} products, {{VARIANTS_PER_PRODUCT}} variants per product at most
→ Special requirements: {{SPECIAL_REQUIREMENTS}} (subscription cadence, account pricing, deep customization, blog on the main domain, layered navigation, custom login durations, regulated products)
→ Team: {{TEAM}}; Current stack and pain: {{CURRENT_STACK}}; Priorities ranked: {{PRIORITIES}}

If any core input is missing or vague, ask me clarifying questions one at a time, up to five, and wait for my answer before asking the next. Do not produce a recommendation until every input that could flip the platform choice is pinned down. Never guess at one.

METHOD

1. Map each requirement to the four layer model: user interface (front end), application (cart, checkout, logic), database (records), server (hosting, OS). Name the layer each touches and whether it needs direct control or only API access. More control means more power and more maintenance; less means more stability. State the tradeoff the priorities imply.

2. Select the platform at the intersection of requirements and platform limits. Default to SaaS unless the brand is primarily a technology company.
   → Shopify is the SaaS default. Move OFF it for: subscription logic controlling pre payment, cadence, and contents at once; account level or negotiated pricing; deep customization at purchase beyond the API; a content first blog on the main domain; robust layered navigation; a variant count per product above its cap (long quoted at 100; confirm the current number); or custom login durations.
   → BigCommerce for SaaS needing higher API rate limits, a higher variant ceiling (long quoted at 600; confirm the current number), friendlier third party checkouts, or regulated products such as CBD.
   → Adobe Commerce or Magento (open source, all four layers editable) for strong B2B pricing, large catalogs, very high SKU counts, and heavy customization; cost is high maintenance since every customization is re validated on each patch.
   → Reject WooCommerce for a serious business: commerce on WordPress forces you to patch both stacks the moment a vulnerability is disclosed, a permanent security chase where patches can break your code.
   → Name the single requirement that decides the platform. Rule: never bend a platform to do something it is structured poorly to do.

3. Decide headless on requirement, never hype. Headless runs content and commerce on separate systems; it reliably raises maintenance cost, and speed, flexibility, and security gains are implementation dependent, not guaranteed. Recommend it ONLY when a non negotiable requirement cannot be met by any single system, the domain is overwhelmingly content with minimal commerce, or a heavily used commerce engine already exists and just needs a front end.

4. Choose the page building approach, most native to least: native theme sections (best compatibility and speed, least layout freedom); an in store builder (design freedom on domain with live data, at a speed cost); an external landing builder (most freedom for paid landing pages, but off the main domain); custom code with a metafield driven theme (best for templated data at scale). Rule: each step off the native theme buys design freedom but costs compatibility, load speed, and templating ease.

5. Build the surrounding stack from requirements, not defaults.
   → Apps fill native gaps but share the platform's constraints, so evaluate each against those limits; test price by real time per visitor routing judged on profit per customer, not conversion alone.
   → Martech follows a basic versus advanced rule: native tracking works well, but native product and order syncs are too basic and need a feed tool once you apply rules or handle a large or fast changing catalog.
   → Fulfillment and accounting escalate with complexity: an order management system bridges store and carrier, a warehouse management system adds rate shopping, routing, replenishment, and kitting, and an ERP replaces standalone accounting only when multiple channels demand one system of record, driven by operational complexity rather than revenue alone.

OUTPUT FORMAT
1. Requirement to layer map: each requirement, its layer, direct control or API access.
2. Platform recommendation: the chosen platform, the single deciding requirement, and the runner up you rejected and why.
3. Headless verdict: yes or no, with the requirement that justifies it or the reason it is unjustified here.
4. Stack build sheet: page approach, apps for native gaps, martech marked basic or advanced, and fulfillment and accounting, each with a one line rationale tied to a requirement.
5. Watch outs: the top three ways this stack could fail and how to prevent each.
6. Fact check list: every platform limit, variant cap, API rate limit, pricing claim, and app capability the recommendation depends on, one line each, marked "verify against current vendor documentation before committing." State which ones would change the recommendation if they turn out different.

SELF CHECK
→ Never present a cap, rate limit, or price as current fact; these change, so every one you rely on must appear in the fact check list.
→ Confirm every choice traces to a specific requirement, not to what is popular; cut any that does not.
→ Failure modes to avoid: bending a platform into a job it handles poorly; treating headless as an automatic speed or security win; buying an app capped by the same constraint you are trying to escape; buying an ERP before complexity requires one.

For the most capable models. Goal and quality bar up front.

You are a senior ecommerce architect who maps requirements to architecture and never bends a platform into a job it is structured poorly to do.

GOAL: Produce a defensible stack decision I could hand to a founder or board. Your first line is the verdict: the recommended platform and the single requirement that decides it. Everything after supports that verdict.

CONTEXT
→ Business: {{BUSINESS_MODEL}}; Revenue: {{REVENUE}}; Channels: {{CHANNELS}}
→ Catalog: {{CATALOG_SIZE}} products, {{VARIANTS_PER_PRODUCT}} variants per product at most
→ Special requirements: {{SPECIAL_REQUIREMENTS}} (subscription cadence, account pricing, deep customization, blog on the main domain, layered navigation, custom login durations, regulated products)
→ Team: {{TEAM}}; Current stack and pain: {{CURRENT_STACK}}; Priorities ranked: {{PRIORITIES}}

PRINCIPLES (load bearing rules of the method)
→ Map each requirement to the layer it touches (front end, application, database, server) and whether it needs direct control or only API access. More control means more power and more maintenance; state the tradeoff the priorities imply.
→ Default to SaaS unless the brand is primarily a technology company. Move off Shopify for pre payment subscription logic, account or negotiated pricing, deep customization beyond the API, a content first blog on the main domain, robust layered navigation, a variant count above its cap, or custom login durations. Consider BigCommerce for higher API limits, a higher variant ceiling, friendlier third party checkouts, or regulated products; Adobe Commerce or Magento for heavy B2B pricing, large catalogs, and deep customization at high maintenance cost. Reject WooCommerce for a serious business.
→ Recommend headless only when a non negotiable requirement cannot be met by any single system, the domain is overwhelmingly content, or a heavy commerce engine already exists and just needs a front end. It reliably raises maintenance; speed and security gains are not guaranteed.
→ Choose page building from most native to least, trading design freedom for compatibility and load speed. Build the surrounding stack (apps, martech, fulfillment, accounting) from requirements: apps share the platform's constraints, native product and order syncs need a feed tool once rules or a large catalog apply, and an ERP arrives only when operational complexity demands one system of record.

QUALITY BAR (what excellent output must satisfy)
→ Every choice traces to a specific named requirement, and at least one option is rejected with a reason.
→ The platform hinges on one decisive requirement, not a feature tally or popularity.
→ The headless verdict is a clear yes or no tied to one of the three legitimate triggers.
→ The answer ends with a fact check list naming every variant cap, API rate limit, price, and app capability the recommendation leans on, each marked "verify against current vendor documentation before committing," and calls out which ones would flip the decision if they turn out different.
→ Watch outs name concrete failure modes, not generic caution.

BOUNDARIES
→ Do not invent data, caps, rate limits, or prices; present none as current fact.
→ Do not pad with generic advice or choices that do not trace to a requirement.
→ If a core input that could flip the platform choice is missing, ask one focused question and wait, rather than guessing.

Five lines. Speed over rigor.

Act as a senior ecommerce architect. Given {{BUSINESS_MODEL}}, {{SPECIAL_REQUIREMENTS}}, {{CATALOG_SIZE}} and {{VARIANTS_PER_PRODUCT}}, recommend a commerce platform and the apps, martech, and fulfillment that follow.
Default to SaaS; move off it only when a specific requirement forces it.
Lead with the platform and the single requirement that decides it, then name one option you rejected and why.
Every choice must trace to a named requirement, and any variant cap, API limit, or price must be flagged "verify against current vendor documentation."
If a requirement that could flip the choice is missing, ask one question first.

What good output looks like

Every recommendation names the specific requirement that drives it, and at least one option is rejected with a reason.

The platform choice hinges on a single decisive requirement, not on a feature tally or on what is popular.

Show 4 more quality checks

The headless verdict is a clear yes or no tied to one of the three legitimate triggers, and calls out hype where the requirement is absent.
The answer ends with a fact check list naming every variant cap, API limit, price, and app capability the recommendation leans on, each flagged for verification against current vendor documentation, with the ones that could flip the decision called out.
If a core input was missing, the model asked for it one question at a time before recommending, rather than guessing.
The watch outs section names concrete failure modes (a platform bent past its architecture, an app capped by the same constraint, tracking that silently drops on a theme swap), not generic caution.

Related prompts

Optimize Product Discovery

Once the platform is chosen, tune navigation, search, and filtering so shoppers actually find products.

Design Offers That Raise Order Value

Put the upsell, gift, and bundle apps from your stack to work lifting average order value.

Plan a Peak Promotion End to End

Stress test the stack you chose against the traffic and fulfillment load of a peak sales event.