Daniel sent us this one — he's been thinking about serverless e-commerce, specifically what frameworks people are actually using to pull it off. And I think he's right that e-commerce feels like the hardest possible test case for a serverless architecture. You have inventory, payments, user accounts, an admin dashboard, probably some kind of cart system that has to work across sessions. That's a lot of state to manage when your whole philosophy is essentially stateless compute.
It really is. And I want to start by naming something the prompt gets exactly right — that moment of surprise when you realize the serverless ecosystem has filled in gaps you didn't even know could be filled. Serverless databases, object storage, edge functions that can talk to a headless CMS. It's not a stripped-down version of the web. It's a parallel universe, as the prompt puts it, and it's been building out quietly for years.
The prompt also makes a comparison I hadn't thought about before. The traditional e-commerce CMS landscape — the big clunky ones — is essentially the same story as WordPress and Drupal for content sites. A couple of dominant players, not much of a long tail. And then Shopify comes along and says, we'll just handle everything for you, which is the Wix model for e-commerce.
That works for millions of merchants. Shopify is genuinely good at what it does. But if you need customization beyond what their templating system allows, or you want to own your stack, or you have complex product configurations, or you're doing anything unusual with pricing or fulfillment — suddenly the SaaS wrapper starts feeling like a cage.
The question is, if you don't want the cage and you don't want the clunky traditional CMS, what does serverless e-commerce actually look like? And Daniel said he's seen some interesting projects on GitHub but wants us to dig into the details. Which I love, because this is exactly the kind of thing you're going to come back with seventeen tabs open about.
I limited myself to twelve. But let me start with the conceptual layer before we get into specific frameworks, because I think the architecture is the interesting part. In a traditional e-commerce setup, you have a monolithic application — your storefront, your cart logic, your checkout, your admin panel, your database — all running on one server or one cluster. When someone adds something to their cart, that state lives in a session on your server. When they check out, the payment processing happens on your server. Everything is co-located.
And the serverless critique of that model has always been: you're paying for a server that's sitting there idle ninety-five percent of the time, and when you get a traffic spike on Black Friday, it falls over anyway because you didn't provision enough capacity.
So the serverless e-commerce architecture breaks all of that apart. You have a static front-end, usually built with Next.js or something similar, deployed to an edge network. Your product data lives in a headless CMS or a specialized commerce engine. Your cart might be managed client-side with local storage, or through a serverless function that writes to a database like PlanetScale or Neon or Turso — all of which are serverless-friendly databases. Your checkout calls a serverless function that talks to Stripe or a payment processor. Your admin panel is a separate application that talks to the same APIs. Everything is decoupled.
The decoupling is the part that makes people nervous, right? Because now instead of one thing to debug, you have six things that all have to talk to each other correctly. But the upside is that each of those six things can scale independently and be swapped out independently.
Which brings me to the frameworks, because this is where the ecosystem has gotten interesting. There are three major open-source headless commerce platforms that have emerged as the serious contenders for serverless e-commerce. The first one, and probably the most mature, is Medusa. Medusa is essentially an open-source alternative to Shopify's backend. It gives you a commerce engine — product management, order management, customer management, fulfillment logic — all exposed as REST APIs or GraphQL. And it's designed from the ground up to run in a serverless environment.
I've seen Medusa popping up everywhere. What makes it serverless-native specifically?
A few things. First, it's built on Node.js and it's designed to be deployed as a set of microservices. You can run the whole thing on a single server if you want, but the architecture assumes you might split the product service, the cart service, the order service into separate serverless functions. Second, it has a plugin system that's modular — payment providers, fulfillment providers, CMS integrations, they're all plugins that you add or remove without touching the core. And third, and this is the part that matters for the serverless model, it's stateless by design. The commerce logic doesn't hold onto anything between requests. State goes to the database or to external services.
You could theoretically run the whole thing on Vercel functions and a serverless database.
You can, and people do. The Medusa team actually has an official starter template for deploying on Vercel with PlanetScale as the database. You get a Next.js storefront, Medusa running as API routes or edge functions, and a separate admin dashboard. The whole thing spins up in about fifteen minutes if you know what you're doing.
That admin dashboard is the part Daniel was asking about specifically — the visual back-end. Because you can't run an e-commerce site by editing JSON files. Someone needs to add products, update inventory, process returns.
Medusa's admin panel is a full React application that talks to the Medusa API. It's not as polished as Shopify's admin, honestly — Shopify has spent years and millions of dollars on their merchant experience. But it's functional, it's customizable, and because it's open source, you can modify it. If you don't like how the product editor works, you change it. That's not an option with Shopify.
That's the trade-off in a nutshell. Shopify gives you a polished experience you can't change. Medusa gives you a rougher experience you can change completely. And for some merchants, that second thing is worth more than the first.
The second major player is Saleor. Saleor is built with Python and Django, which is interesting because it's not the JavaScript ecosystem, but it's GraphQL-native. Every interaction with Saleor goes through a single GraphQL endpoint. And they've put a lot of work into making that GraphQL API comprehensive — you can query products, variants, collections, orders, users, everything through one interface.
GraphQL matters for serverless because?
Because in a serverless architecture, you're often paying for compute time and database queries. GraphQL lets the front-end request exactly the data it needs in a single round trip. With REST, you might need to hit three or four endpoints to assemble a product page — product details, pricing, inventory, related items. With GraphQL, it's one query. That's fewer function invocations, less cold start overhead, lower latency for the user.
That's a concrete advantage I hadn't connected before. So Saleor's GraphQL-first design isn't just a developer experience preference — it's an architectural optimization for the serverless model.
And Saleor has also invested heavily in their dashboard. They have a project called Saleor Dashboard that's a separate React application, and it's one of the better open-source e-commerce admin panels. It handles product variants, digital products, multi-channel sales, all of that. The dashboard talks to the same GraphQL API that your storefront uses, so there's no split between the admin backend and the customer-facing backend. It's the same API.
Which means if you can build a feature into your storefront, you can build it into your admin panel too. That's elegant.
The third one I want to mention is Vendure. Vendure is newer, built with TypeScript and NestJS, and it's designed for what they call "headless commerce at any scale." What's interesting about Vendure is that it's more opinionated about the serverless deployment model. It has first-class support for worker processes — background jobs for things like sending order confirmation emails or recalculating inventory — and those workers can run as separate serverless functions. So you're not trying to cram background processing into your request-response cycle.
That's a real problem with serverless. If someone places an order and you need to send three emails, update inventory across five warehouses, and trigger a fulfillment workflow, you can't do all of that in the three-second timeout of a serverless function.
Right, and Vendure solves this by splitting synchronous operations — add to cart, process payment — from asynchronous operations — send emails, update inventory — into different execution contexts. The synchronous stuff runs in your API functions. The async stuff goes to a job queue that worker functions pick up. It's the right architecture for serverless, and Vendure bakes it in rather than making you build it yourself.
We've got Medusa, Saleor, Vendure. Three open-source headless commerce engines. But Daniel also mentioned seeing interesting projects on GitHub, and I feel like there's a layer below these that's worth talking about. The build-it-yourself approach.
And this is where the serverless ecosystem really shines. If you don't need a full commerce engine — if you're selling five products, or you're doing something unusual like selling digital goods with custom licensing — you can assemble an e-commerce site from smaller pieces. You might use Stripe for payments and subscriptions, a headless CMS like Sanity or Contentful or Strapi for product data, and Next.js for the storefront. The cart can be managed with a library like use-shopping-cart, which handles cart state client-side and syncs with Stripe's API.
That's a completely valid e-commerce site with zero commerce engine.
And I've seen people do remarkable things with this approach. There's a project called Next.js Commerce that Vercel maintains, which is essentially a starter kit for this exact pattern. It gives you a production-ready storefront with cart, checkout, product pages, search — all the basics — and it's designed to plug into different backends. They have providers for Shopify, for BigCommerce, for Saleor, for Medusa, and for a generic "local" provider that just uses a JSON file as the product database.
The JSON file provider is hilarious to me. It's the "I have three products and I'm not apologizing for it" approach.
It's useful though. If you're a musician selling five t-shirt designs and a vinyl record, you don't need a commerce engine. You need a product listing that doesn't change for six months and a checkout flow. A JSON file and Stripe Checkout is the right tool for that job. The over-engineering is what the SaaS platforms push you toward — they want you to think you need their entire stack.
That's the spectrum. On one end, you have the Shopify-style all-in-one SaaS. On the other end, you have "I listed my products in a JSON file and I'm using Stripe." In the middle, you have these headless commerce engines that give you the admin tools and business logic without locking you into a hosted platform.
I want to talk about where on that spectrum the serverless model actually creates new possibilities that didn't exist before. Because the prompt mentions something really insightful — that e-commerce feels like it should be one of the hardest things to do serverlessly. And it is, in some ways. But it also benefits from serverless in ways that a traditional content site doesn't.
Walk me through that.
Think about what an e-commerce site actually does. Ninety percent of the requests are reads — browsing products, viewing categories, searching. Those are static or cacheable. A serverless edge network like Vercel's can serve those from a CDN point of presence near the user, with essentially zero server cost. The other ten percent — add to cart, checkout, account management — those need compute. But they're intermittent and spiky. You might get fifty checkouts in an hour and then nothing for three hours.
Which is exactly the usage pattern serverless was designed for. You're not paying for a server to sit there waiting for checkouts.
And here's where it gets interesting. With a traditional monolithic e-commerce site, your product pages and your checkout share the same infrastructure. If your checkout gets slammed on Black Friday, your product pages slow down too. With a decoupled serverless architecture, your product pages are static files on a CDN — they don't care about checkout load at all. Your checkout functions scale independently. Your admin panel scales independently. You've isolated the failure domains.
That's the resilience argument that people don't talk about enough. The decoupling isn't just about developer convenience — it's about blast radius. If your inventory management function goes down, your customers can still browse and buy. If your search index has a problem, your checkout still works. In a monolith, one bad deployment can take down the whole store.
There's another angle that's specific to e-commerce. In a traditional setup, if you want to experiment with a new product page layout or a new checkout flow, you're doing it in a big codebase that touches everything. You deploy carefully, you run it past QA, you schedule a maintenance window. In a serverless headless setup, your storefront is a separate application from your commerce logic. You can redesign the entire shopping experience without touching the backend at all. You can A/B test checkout flows by deploying different front-end versions to different URL patterns. The backend API doesn't care what the front-end looks like.
That's the composable commerce pitch, right? Which is the term Vercel uses for this whole approach.
Composable commerce is the idea that you assemble your e-commerce stack from best-of-breed components rather than buying a monolithic platform. Your CMS, your commerce engine, your search, your payments, your personalization — each is a separate service that you choose independently and compose through APIs. Vercel has a whole solutions page for this, and they've built integrations with most of the major players.
The integrations are the part that makes this practical rather than aspirational. Because "compose it yourself from APIs" sounds great until you're the one writing the integration code.
And this is where the ecosystem has matured significantly. Vercel has official integrations for Shopify, BigCommerce, Saleor, Medusa, and several others. These aren't just "here's an API, good luck." They're pre-built connectors that handle the authentication, the data fetching, the cart synchronization, the webhook processing. You configure a few environment variables and suddenly your Next.js storefront can pull products from your commerce backend.
Which makes the barrier to entry dramatically lower than it was even three years ago.
And I think that's the story the prompt is really getting at. The serverless ecosystem has been filling in the gaps so systematically that things that seemed impossible — or at least impractical — five years ago are now starter-template territory. Serverless databases seemed like an oxymoron. Now we have PlanetScale, Neon, Turso, all built for the serverless execution model. Object storage with edge access seemed like a niche need. Now it's a checkbox on every cloud provider. Background jobs in serverless seemed like a fundamental limitation. Now we have QStash and Inngest and Trigger.
There's a pattern here that I think applies beyond e-commerce. The initial version of a new paradigm always looks limited because the ecosystem hasn't caught up yet. People look at the limitations and say, "well, you can't do X, so this paradigm is only good for simple use cases." And then over the next five years, the ecosystem systematically eliminates each of those limitations. And by the time it's mature, the things that seemed impossible are just...
That's exactly what happened with cloud computing in general. "You can't run a database in the cloud, the latency will kill you." Then Amazon launched RDS and suddenly you could. "You can't do machine learning without on-premise GPUs." Then cloud GPU instances appeared. The pattern repeats.
Let me ask the skeptical question. Daniel mentioned that he assumes there are sacrifices versus a traditional unified setup. What are the actual sacrifices? Not the ones people assume, but the real ones?
The first real sacrifice is operational complexity. When you have a monolithic e-commerce application, you have one thing to monitor, one thing to deploy, one thing to debug. When you have a composable serverless setup, you have five or six services, each with its own dashboard, its own logging, its own pricing model, its own quirks. The cognitive load of understanding your own stack goes up significantly.
If something breaks, you're playing the blame game across vendors. Is it a Vercel issue, a PlanetScale issue, a Stripe issue, or did your own function just time out?
The second sacrifice is vendor lock-in of a different kind. People worry about lock-in with platforms like Shopify, but composable commerce has its own lock-in. If you build your entire storefront around Medusa's API patterns, migrating to Saleor later is not trivial. If you use Vercel's edge functions with their specific runtime limitations, moving to Cloudflare Workers or AWS Lambda requires rewriting. You're not locked into one vendor — you're locked into five vendors, each of which you'd have to untangle from separately.
That's the distributed lock-in problem. Instead of one golden handcuff, you have five silver ones.
That's a perfect way to put it. The third sacrifice is performance predictability. In a traditional setup, you know your server's specs and you know your database connection pool size. In a serverless setup, you're subject to cold starts, connection pooling limitations with serverless databases, and the sometimes unpredictable latency of chaining multiple API calls across different services. Most of the time it's fine. When it's not fine, it's harder to diagnose why.
The fourth sacrifice, which I think is the one that actually matters most for e-commerce specifically, is real-time inventory. If you have fifty people trying to buy the last three units of a product, you need transactional integrity. You need to decrement inventory atomically and tell the forty-seventh person "sorry, sold out" before they complete checkout. That's hard in a distributed system, and it's especially hard when your inventory logic is a serverless function that could have a cold start while someone's credit card is being processed.
That's the hard problem. And the solutions are not perfect. You can use database-level locking, but that creates contention. You can use optimistic concurrency, but that means some customers will complete checkout only to get a "sorry, actually that was out of stock" email five minutes later, which is a terrible experience. You can over-provision inventory buffers, but that means leaving money on the table. None of the solutions are as clean as a monolithic application with a transactional database.
For a high-volume flash-sale scenario — Supreme drops, concert tickets, limited sneaker releases — serverless e-commerce might not be the right tool.
I would say it's the wrong tool for that specific use case, unless you're willing to build a custom inventory reservation system that sits outside the serverless request-response cycle. And some people do that. But at that point you're building infrastructure, not running a store.
Which brings us back to something the prompt mentions — that serverless isn't the right approach for every project. And I think the flash sale scenario is the clearest example of where it isn't.
But for the vast majority of e-commerce — the long tail of merchants selling hundreds or thousands of products, with steady traffic patterns and occasional spikes — the serverless model is not just viable, it's probably optimal. You get the resilience, the iteration speed, the cost efficiency, and you avoid the operational burden of managing servers.
Let's talk about some real examples. You mentioned Next.js Commerce earlier. Who's actually using these frameworks in production?
Medusa has some impressive case studies. There's a company called Tekla Fabrics that migrated from Magento — which is one of those big clunky traditional CMSs — to a Medusa and Next.They saw their page load times drop by about sixty percent and their conversion rate improve. There's a European supplement brand called Naka that uses Medusa with a custom storefront. The Medusa team publishes these case studies pretty regularly.
On the Saleor side?
Saleor is used by a few larger enterprises. They have a reference implementation with a European electronics retailer that handles about fifty thousand products across multiple markets. The thing about Saleor is that because it's Python and Django, it appeals to teams that already have Python expertise and don't want to switch to JavaScript for their backend. That's a real consideration — the framework choice is often determined by who you can hire.
That's a point that gets lost in the framework debates. The best framework is the one your team can actually work with. If you're a Python shop, Saleor is going to be a much better fit than Medusa, even if Medusa has more GitHub stars or whatever.
Vendure has found a niche with B2B commerce, which is interesting. B2B e-commerce has different requirements — bulk ordering, custom pricing per customer, purchase order workflows, approval chains. Vendure's architecture, with its emphasis on worker processes and job queues, handles those workflows more naturally than the request-response model.
We've got Medusa for general headless commerce, Saleor for Python shops and GraphQL enthusiasts, Vendure for B2B and complex workflows. What about the Shopify question? Because I think a lot of people listening are going to ask: if I'm already on Shopify, why would I move to any of this?
The answer is usually one of three things. One, you've hit the limits of Shopify's templating system and you want full control over your storefront. Shopify's Liquid templating language is fine for basic customization, but if you want to build a unique shopping experience, you eventually hit a wall. Two, you're paying substantial transaction fees to Shopify and you want to use your own payment processor. Three, you need multi-market or multi-brand capabilities that don't fit neatly into Shopify's store model.
Shopify actually supports the headless approach themselves through their Storefront API. You can use Shopify as your commerce engine and build a completely custom front-end with Next.So it's not even an either-or.
That's a really important point. Shopify's Storefront API gives you access to your products, collections, cart, and checkout through GraphQL. You can keep Shopify as your backend — your product management, your inventory, your order processing — and build a headless storefront that talks to it. Several major brands do exactly this. Allbirds, the shoe company, runs a headless Next.js storefront on top of Shopify. So does Staples, the office supply company.
The "headless Shopify" pattern is essentially: keep the commerce engine you know, replace the front-end you don't like. That's a much smaller migration than moving your entire commerce operation to Medusa or Saleor.
It's often the right first step. Move your storefront to a headless architecture, get comfortable with the serverless model, and then evaluate whether you want to replace the backend too. You don't have to boil the ocean.
The prompt also mentions CRMs and ERPs as other categories that seem like bad fits for serverless but might not be. I'm curious about that parallel. Are we seeing the same pattern play out there?
We are, though it's earlier in the cycle. There are headless CRM platforms starting to emerge — things like Twenty, which is an open-source Salesforce alternative, or Attio, which is more of a programmable CRM. The idea is the same: separate your data layer from your presentation layer, expose everything through APIs, and let people build custom interfaces on top.
A CRM has even more state than an e-commerce site. You've got contact records, deal pipelines, activity histories, email integrations. That's a lot of mutable data.
It is, and I think the serverless CRM story is less mature than the serverless e-commerce story. The database layer is harder — you need real-time collaboration, you need conflict resolution, you need to handle offline edits. These are problems that serverless databases are still figuring out. I'd say serverless CRM is where serverless e-commerce was about three or four years ago. Possible, demonstrated, but not yet starter-template territory.
The pattern holds. The ecosystem fills in the gaps over time, and each category goes through the same arc. Content sites first, because they're the easiest. Then e-commerce, which is where we are now. Then CRMs and ERPs, which are coming.
I think the arc is accelerating. Each category learns from the previous one. The serverless databases that were built for e-commerce use cases — handling inventory transactions, cart state, order history — those same databases will eventually handle CRM workloads. The background job infrastructure built for order processing will handle deal pipeline automation. The composable architecture patterns transfer.
One thing I want to circle back to, because I think it's the most practical question for someone listening who's thinking about building a serverless e-commerce site right now. If you're starting from scratch today, what do you actually choose?
It depends on what you're optimizing for. If you want the fastest time to market and you're comfortable with the JavaScript ecosystem, I'd say start with Medusa and their Vercel deployment template. You get a working store with an admin panel in an afternoon. If you're a Python team, go with Saleor. If you're doing something B2B or complex, look at Vendure. If you just want to sell a handful of products and don't need an admin panel, use Next.js Commerce with the local provider and Stripe.
If you're already on Shopify and just want a better front-end?
Use the Shopify Storefront API with Next.Vercel maintains a Shopify provider that handles the integration. You get the best of both worlds — Shopify's battle-tested commerce engine and a modern headless storefront you control completely.
That's a surprisingly clear answer for a space that feels complicated.
The space is complicated because there are a lot of options, but the decision framework is actually pretty straightforward once you map it to your constraints. Team skills, product complexity, traffic patterns, customization needs. Those four factors will point you to one of the paths we've discussed.
I think the bigger takeaway from this whole conversation is what the prompt was really getting at — that moment of discovering the serverless ecosystem is much richer than you assumed. You start out thinking serverless means static sites and simple APIs. Then you discover serverless databases. Then you discover headless commerce engines. Then you realize people are running full e-commerce operations, CRMs, even ERPs on this architecture. And the thing that seemed like a toy turns out to be a legitimate platform.
It's the "wait, you can do that?And I think every developer who gets into serverless goes through it. The initial skepticism is healthy. The discovery is fun. And the eventual realization that the limitations are mostly in your assumptions, not in the technology, is exciting.
Now: Hilbert's daily fun fact.
Hilbert: In nineteen sixty-four, linguist Kenneth Hale published a landmark paper on the kinship terminology of the Warlpiri people of central Australia, claiming the system contained eighty-seven distinct relationship terms — a figure that was later corrected in nineteen seventy-one by anthropologist Nancy Munn, who demonstrated that Hale had inadvertently double-counted seventeen terms due to a transcription error in his field notes, bringing the actual count to seventy terms.
...right.
The next time someone tells you serverless can't handle real workloads, just remember — people are running e-commerce empires on edge functions and serverless databases, and the gap between what you think is impossible and what's actually shipping gets smaller every quarter. The ecosystem isn't done filling in the gaps.
If you're curious about any of the frameworks we mentioned — Medusa, Saleor, Vendure, Next.js Commerce — we'll have links in the show notes. This has been My Weird Prompts, produced by the ever-mysterious Hilbert Flumingtop. Find us at myweirdprompts.com or wherever you get your podcasts.
I'm Corn.
I'm Herman Poppleberry. Talk to you next time.
