Is Webflow Good for Ecommerce? What the SKU Cap Actually Costs
Webflow's ecommerce plans cap items and charge a transaction fee on top. This storefront's entire commerce stack — entitlements, checkout, webhook — is 843 lines with no cap at all.
Webflow is good for ecommerce when the catalog is small and the brand experience matters more than raw margin — its visual builder has no real rival there. What it isn't built for is a catalog that outgrows its plan: Webflow's Ecommerce tiers cap item count and charge a transaction fee on top of the subscription (Standard $29/mo with a 2% fee and a 500-item cap, rising to Plus at $74/mo, 0% fee, 5,000 items, and Advanced at $212/mo for 15,000 — figures per Digidop's 2026 Webflow pricing breakdown, annual billing). A coded storefront has no such ceiling, at the cost of building the plumbing yourself.
What the plan actually gates
| Webflow Standard | Webflow Plus | Webflow Advanced | |
|---|---|---|---|
| Monthly cost (annual billing) | $29 | $74 | $212 |
| Transaction fee | 2% | 0% | 0% |
| Item/SKU cap | 500 | 5,000 | 15,000 |
| Code export | Static markup only — no CMS, no forms, no ecommerce logic | Same | Same |
| Checkout | Webflow-hosted | Webflow-hosted | Webflow-hosted |
None of the three tiers removes the cap — they raise it and drop the fee. A catalog of 20,000 SKUs, or one that plans to get there, is off every Webflow ecommerce plan regardless of budget; the platform's own upgrade path stops at Advanced. And every tier shares the same limitation Webflow vs. Next.js for a Landing Page already covers for marketing pages generally: the paid code-export feature ships static HTML, not the CMS or ecommerce logic behind it — there's no "eject and keep the store" option on any plan.
What a coded storefront looks like instead
This storefront's own commerce stack has no per-SKU pricing tier at all, because the entitlement question isn't "how many products," it's "which one did this buyer pay for":
// src/lib/entitlements.ts — the entire access-control engine, 75 lines
export type SlotKind = "template_single" | "all_templates" | "all_access";
export function slotCovers(slot: Slot, target: DownloadTarget): boolean {
if (slot.status !== "active") return false;
switch (slot.kind) {
case "all_access":
return true;
case "all_templates":
return target.framework !== "backend";
case "template_single":
return (
slot.productSlug === target.productSlug &&
target.framework !== "backend"
);
}
}
That function, plus the checkout wiring (src/lib/actions/checkout.ts), the signed webhook handler (src/app/api/webhooks/lemonsqueezy/route.ts), and the gated download route (src/app/api/download/route.ts), come to 843 lines across five files — the whole commerce surface for a 111-product catalog, with no SKU cap built in anywhere because there's nothing counting SKUs. Both the webhook route and the download route pin export const runtime = "nodejs" explicitly, because HMAC signature verification (node:crypto) and signed-URL generation both need the full Node runtime — a real constraint a hosted platform like Webflow never exposes to you, because it's already decided for you.
The tradeoff is exactly what it looks like: Webflow's SKU cap and transaction fee buy a working store with zero of that code written; the 843 lines above buy no cap and no fee, at the cost of owning webhook idempotency, signature verification, and download security yourself. Selling a Digital Product from Next.js with LemonSqueezy Checkout walks through building that stack; it isn't repeated here.
Worth naming directly: this catalog's own 111 products would fit inside Webflow's smallest ecommerce tier by count alone — 500 items is not the constraint that ruled Webflow out. The constraint is the shape of what's being sold. slotCovers above has to answer "does owning all_templates cover this specific product's backend edition?" — a many-products-per-purchase, tier-ranked entitlement question that a flat product-catalog CMS collection has no field for. A store selling 20,000 physically distinct SKUs at one price each is a Webflow-shaped problem long before it's a coded-storefront problem; a store selling tiered access to a growing catalog is a coded-storefront problem at any size.
What outgrowing Webflow's ecommerce plan actually costs later
The cap isn't the only one-way door. Every Webflow ecommerce plan's code-export feature — the escape hatch for outgrowing the platform generally — ships static markup only, with no cart, checkout, or CMS data attached. That means migrating off Webflow ecommerce later isn't a lift-and-shift: the product data can be exported (CSV, or the CMS API on paid plans), but the checkout flow, the payment integration, and any custom logic layered on top of the ecommerce collections have to be rebuilt from nothing on whatever platform comes next — the same 843 lines this storefront already owns, written for the first time, under migration pressure rather than as a deliberate build. Building the coded version first avoids that specific one-way door; it doesn't avoid the SKU-cap tradeoff going the other way, which is real and often the right call for a catalog that will never need it.
The decision isn't really "Webflow vs. code" — it's what you're willing to own
Shopify vs. a Next.js Storefront frames this as four jobs a hosted platform does for you: checkout and payments, tax, inventory truth, and day-to-day operations. Webflow's ecommerce plan answers the same four questions, just with a visual builder instead of an admin API:
| Job | Webflow's answer | A coded storefront's answer |
|---|---|---|
| Checkout & payments | Webflow-hosted, Stripe or PayPal behind it | You wire the processor (LemonSqueezy, Stripe) and own the webhook |
| Tax | Automated by plan | You calculate it, or a merchant-of-record processor does |
| Inventory truth | The CMS collection is the source of truth, capped by plan | Whatever your own database says — no external cap |
| Day-to-day operations | Webflow's admin UI | Your own dashboard, or none, if the catalog doesn't need one |
Neither answer is universally right. A single founder selling under 500 SKUs with no engineering time gets a working store from Webflow in a weekend, transaction fee included. A catalog with unusual pricing logic — bundles, license tiers, entitlement rules that don't map to "one SKU, one price" — runs into Webflow's ecommerce data model before it runs into the item cap, because Webflow's CMS collections weren't built for slot-based entitlements like all_templates or all_access above; that logic has nowhere to live in a no-code data model at all.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| Catalog is approaching the 500-item cap on Standard | Webflow enforces the cap platform-wide, not per-collection | Upgrade to Plus (5,000 items, 0% fee) or migrate the data model off Webflow entirely |
| Need bundle pricing or tiered access, not one-SKU-one-price | Webflow's ecommerce CMS models a flat product catalog | Either simulate it with CMS reference fields, or move that logic to a coded backend — see the entitlement engine above |
| Code export doesn't include cart or checkout logic | Webflow's export is static HTML/CSS/JS only, by design on every plan | There is no workaround inside Webflow; migrate the storefront to a framework that owns its own logic |
| Transaction fee is eating margin on a growing catalog | Standard's 2% fee applies to every order regardless of catalog size | Upgrade to Plus/Advanced (0% fee) once volume justifies the higher base cost, or move to a payment processor with a flat per-order fee instead |
| Webhook-driven entitlements (buy once, own forever) don't map to a subscription-shaped CMS collection | Webflow ecommerce assumes a shopping-cart model, not a license/entitlement model | A coded backend with its own entitlement table (like the 75-line function above) is the fix, not a Webflow workaround |
FAQ
Is Webflow good for ecommerce at small scale? Yes — under a few hundred SKUs, with standard one-price-per-product logic, Webflow's visual builder and hosted checkout genuinely save the engineering time a coded storefront costs. The 2% Standard-tier fee is the price of that speed.
What's the real ceiling on Webflow ecommerce? Two things move together: the item cap (500 → 5,000 → 15,000 across the three tiers) and the data model itself, which assumes a flat catalog. A business with real per-product logic — bundles, license tiers, entitlements — hits the second ceiling before the first.
Does Webflow's code export solve the lock-in problem? No. Every ecommerce plan's code export is static markup, not the CMS, cart, or checkout logic behind it. There's no path to "export the store and self-host it" on any tier.
How does this compare to Shopify instead of Webflow? Shopify's ecommerce data model is closer to what a coded storefront needs (its Storefront API is genuinely queryable), but the transaction-fee and app-marketplace cost structure is a different tradeoff than Webflow's flat plan tiers — see Shopify vs. a Next.js Storefront for that comparison specifically.
Templates in this post
ASoc Reach, ASoc Relay, and ASoc Remit are three of the 66 landing templates in this catalog — none ships ecommerce logic itself, but each pairs with the same LemonSqueezy checkout and entitlement engine described above once a Buy button is added.
Browse the full set: Next.js landing page templates and Tailwind landing page templates. For the checkout build itself, see Selling a Digital Product from Next.js with LemonSqueezy Checkout.
