The Ecommerce Vacuum
Every option for selling online is either too expensive, too broken, or too locked down. The businesses stuck in the middle have no good option. Here's why — and what we're thinking about.
Here’s the choice most businesses face when they want to sell online:
Option A: pay a SaaS platform a meaningful percentage of your revenue, process payments through their stack at their rates, and lease access to your own customer data, inventory, and transaction history inside a system you’ll never own. When you want to leave, you’ll discover that “your data” exports in a format that’s technically complete and practically useless.
Option B: build on open source — most likely WordPress with WooCommerce — and inherit a system that was designed to be a blog. A compact car that’s been modified, extended, and bolted onto until it technically does ecommerce, but carries twenty years of architectural decisions that were never made with commerce in mind. Every plugin is a potential attack vector. Every update is a potential breaking change. Every year, the technical debt compounds.
Option C: go headless. Decouple your frontend from your backend. Use modern frameworks for the storefront and mature commerce engines for the operations. This is architecturally correct. It’s also priced so far out of reach for most small and mid-sized businesses that it might as well not exist.
Most businesses end up in Option A — not because it’s the best choice, but because the alternatives require either technical sophistication they don’t have or budgets they can’t justify. The SaaS platforms know this. Their entire business model depends on it.
The SaaS Extraction Model
I want to be precise about what “too expensive” means in this context, because it’s not just the subscription fee.
SaaS ecommerce platforms generate revenue from multiple layers simultaneously. There’s the platform subscription — the number on the pricing page. There’s the payment processing, which is typically bundled at flat rates that carry significant spreads over interchange. There’s the app marketplace, where third-party functionality that should be native costs additional monthly fees. There’s the theme marketplace. The transaction fees. The bandwidth overages. The premium support tiers.
We’ve spoken with clients spending well into six figures annually with SaaS platforms. Not because their businesses are massive — because the cost structure compounds. And the switching cost is designed to compound faster.
Your product catalog, your customer data, your order history, your integrations — they live inside the platform. Technically exportable. Practically trapped. The data format is proprietary enough that migrating to another system requires rebuilding, not transferring. That’s not an accident. That’s the retention strategy.
The platform doesn’t need to be the best option. It just needs to be less painful than leaving.
The WordPress Reality
WordPress powers a significant percentage of ecommerce sites, and it deserves credit for making online selling accessible. But let’s be honest about what you’re building on.
WordPress was designed as a blogging platform in 2003. Every ecommerce capability it has today is an extension — WooCommerce, payment plugins, shipping integrations, inventory management — bolted onto a content management system that was architected around posts, pages, and comments.
The result is a system that works until it doesn’t. Plugin conflicts break checkout flows. Security vulnerabilities in one extension expose the entire site. Performance degrades as plugin count increases because each one adds database queries, HTTP requests, and potential failure points. Updates to WordPress core can break WooCommerce. Updates to WooCommerce can break payment plugins. Updates to payment plugins can break theme integrations.
This isn’t WordPress being bad at what it does. It’s WordPress being asked to do something it was never designed for. You can modify a compact car to haul freight, but the chassis will remind you it wasn’t built for that — every time you hit a bump.
For many small businesses, WordPress is still the right choice — it’s accessible, it’s ownable, and the ecosystem is vast. But pretending it’s a purpose-built commerce platform creates expectations it can’t reliably meet.
The Headless Promise — and the Headless Price Tag
Headless commerce separates concerns correctly. Your storefront — what customers see and interact with — is decoupled from your commerce engine — inventory, orders, payments, fulfillment. Each layer can be optimized independently. The frontend can be built with modern frameworks that deliver blazing performance. The backend can use a mature, purpose-built commerce system.
This is the right architecture. It’s also inaccessible to most of the businesses that would benefit from it.
Custom headless builds require frontend developers who understand modern frameworks, backend integration expertise, API architecture design, and ongoing maintenance across two systems instead of one. The development cost prices out small and mid-sized businesses. The operational complexity prices out teams without dedicated technical resources.
The platforms that offer “headless-ready” commerce backends still charge SaaS-level fees for the privilege. You’ve decoupled your frontend, but you’re still paying platform rates for the backend — and still processing payments through their stack in many cases.
So the market sits in a vacuum. The architecturally correct solution exists but is economically inaccessible. The accessible solutions are either extractive or architecturally compromised. And the businesses in the middle — too large for a simple template, too small for a custom headless build — have no good option.
What We’re Thinking About
I’m going to be honest: we haven’t solved this yet. But we’ve made some decisions about the direction, and the thinking behind them is worth sharing.
On the frontend, we’ve committed to static-first builds. For us, that’s Astro with Svelte components. The output is pre-rendered HTML — no server-side processing on every page load, no attack vectors from a runtime environment, no database queries on every request. The performance is inherently fast because there’s nothing to slow it down. The hosting cost is inherently low because static files are cheap to serve. The security posture is inherently strong because there’s no server-side application to exploit.
This is a philosophical commitment as much as a technical one. We’re choosing a stack where the output is portable by nature. The files a client receives are standard HTML, CSS, and JavaScript. There’s no proprietary framework underneath. No vendor-specific runtime. Another developer could pick up the project without needing access to our systems or our tooling. The architecture itself resists lock-in.
On self-service content management, we’re cautious. CMS integration is the obvious answer for clients who need to update content without developer involvement. But CMS platforms can become their own form of lock-in — your content lives in their system, structured in their format, accessible through their API. If the platform changes pricing, changes terms, or disappears, your content migration becomes a project in itself.
We’re exploring how to give clients editorial control without creating a new dependency. The answer probably isn’t “no CMS” — it’s choosing CMS architecture carefully, ensuring content is stored in portable formats, and maintaining the principle that the client owns their content in a form they can take elsewhere.
On the backend commerce layer, the question is still open. Mature, well-built commerce backends exist. They handle inventory, orders, payments, tax calculation, and fulfillment reliably. Connecting a high-performance static frontend to a robust commerce backend is architecturally sound. The challenge is finding — or building — a backend layer that doesn’t reintroduce the extraction economics we’re trying to escape. The systems exist. The integration patterns exist. What doesn’t exist yet is a package that makes this accessible at a price point that serves the businesses stuck in the vacuum.
That’s the problem we’re working on.
The Trap We’re Trying to Avoid
Here’s the part I think about most.
Every SaaS platform that now charges six figures a year to businesses that can’t easily leave started with the same pitch: we’re simpler, we’re more affordable, we’re better than what you’re using now. And at the beginning, they were.
The extraction doesn’t start on day one. It starts when the growth pressures kick in — when investor expectations demand increasing revenue per customer, when churn reduction becomes more profitable than value delivery, when the switching cost you’ve accumulated in your user base becomes your most valuable asset.
We are explicitly trying not to build that. Our payments philosophy — processor freedom, interchange transparency, the client owns the relationship — applies to everything we build. If we create a commerce solution, the client owns their storefront code, owns their content, owns their customer data, and can process payments through whatever acquirer serves them best. If they want to leave, they leave with everything. Complete. Portable. Documented.
That’s a structurally harder business to build. It means we compete on the quality of our work and the value of our guidance, not on the stickiness of our platform. It means every client who stays is a client who chose to stay. It means we have to keep earning the relationship.
The Nugget: “The platform doesn’t need to be the best option. It just needs to be less painful than leaving.”
This is part of a series on how we think about payments, technology, and building a business that doesn’t require client confusion to be profitable.