This is a story about building something technically impressive that couldn't survive as a business. Everything worked. The architecture was solid. The client loved it. And we still had to abandon the model.
If you're building platforms on top of WordPress — especially headless — this might save you six months of work.
The idea
A few years ago, before AI-assisted development was a thing, my team and I set out to build a platform that would let anyone spin up a fully functional ecommerce store through a guided wizard.
The pitch was simple: answer a few questions, pick a template, and get a live WooCommerce store with sample products, payment gateway configured, and a custom domain — all automated. No technical knowledge required.
The twist: the frontend was headless. Every store ran a decoupled frontend that pulled data from WordPress via the REST API. The result was a shopping experience that felt like a native app — instant page transitions, snappy product filtering, smooth cart interactions. No full page reloads, no WordPress frontend overhead.
We were proud of it. Rightfully so — it was a serious piece of engineering.
The stack
We ran everything on OVH Cloud with Docker. The core architecture:
WordPress Multisite as the backend. Each new store was a subsite on the network. This gave us centralized plugin management, shared user tables, and a single WordPress installation to maintain. When we updated a plugin, every store got it.
Automated provisioning. When a user completed the wizard, the system created the multisite subsite, pointed a domain via DNS API, installed WooCommerce with preconfigured settings, populated sample products and categories, and generated the headless frontend build.
Decoupled frontend. Each store had its own static frontend (built with Gridsome — a Vue-based static site generator that was popular at the time) that consumed the WordPress REST API. This was pre-rendered and served from a CDN. Page loads were sub-200ms. Product pages felt instant. The checkout was smooth.
Docker orchestration. Everything ran in containers — the WordPress multisite, the database, Redis for object caching, Nginx as reverse proxy, and the build pipeline for the frontends.
It was beautiful. It was fast. It worked.
The client
We sold the platform to one of our agency clients. They wanted a way to offer ecommerce stores to their small business customers without building each one from scratch.
They're still using it today — you can see the original platform at megicart.it. Their customers love the speed of the frontend. The admin is standard WooCommerce, so anyone can manage products and orders. Updates are centralized. Support is straightforward.
One client, one multisite, a manageable number of stores. It works great in that context.
Where it broke
The first client worked great. One store, manageable product catalog, builds running smoothly. We were confident.
So we added two more test stores to the multisite to simulate what a real platform would look like. Three stores total on a €68/month OVH Cloud instance. Not a cheap server — decent specs, solid performance for most workloads.
Then all three stores triggered builds around the same time. A product update on store one. A page edit on store two. A theme change on store three.
The server froze. Completely. CPU pegged at 100%, memory exhausted, SSH unresponsive. We had to hard reboot from the OVH panel.
Three stores. Not thirty. Not three hundred. Three.
The problem was fundamental: a headless frontend needs to be built. Every time a store owner changes a product, updates a page, or modifies anything, the static frontend regenerates. That means pulling every product from the WordPress REST API, rendering every product page, every category page, every filtered view. For a store with hundreds of products, a single build consumes several GB of RAM and a full CPU core for minutes.
One build at a time? Fine. Two or three concurrent builds on the same server? Everything dies.
The math that killed it
We did the math we should have done before building the platform.
To run just 10 stores without builds crashing each other, we needed a server with enough CPU and RAM to handle 3-4 concurrent builds. That meant upgrading to an instance 4-5x more expensive — €250-350/month minimum.
For 50 stores, we'd be looking at €500-600/month in infrastructure alone. At that point, each store needs to pay €10-12/month just to cover servers. Add development, support, and margin, and the price per store hits €25-40/month.
Meanwhile, a traditional WordPress site with good hosting (not headless, just well-optimized with caching and a CDN) delivers sub-500ms page loads at €5-8/month per site. The headless frontend was objectively faster — sub-200ms — but was that extra speed worth 4-5x the infrastructure cost? For a small business owner selling candles or running a restaurant menu? No.
What we got wrong
We never tested concurrent builds before building the platform. We tested one store, it worked, and we assumed three would work three times as well. That's not how shared server resources work. One build is fine. Three concurrent builds on the same machine is a completely different problem.
We optimized for the wrong metric. We were obsessed with frontend performance (sub-200ms loads) without calculating whether that performance justified the infrastructure cost. A well-configured traditional WordPress site with a CDN delivers sub-500ms loads at a fraction of the cost.
Multisite amplified the problem. WordPress Multisite shares everything — database, PHP processes, memory. When one store triggers a heavy build, every other store on the network competes for the same resources. Isolated instances would have been more resilient, but then you lose the centralized management that made multisite attractive in the first place.
We fell in love with the architecture. The headless setup was technically beautiful. The frontend was objectively faster. The developer experience was great. But none of that matters if three stores crash a €68/month server. We kept trying to optimize the build pipeline instead of questioning whether headless was the right choice for this business model.
What I'd do differently
If I were building this today, I'd make three different choices.
Skip headless for this use case. A traditional WordPress frontend with a good theme, proper caching, and a CDN delivers "fast enough" for small business ecommerce. The difference between 200ms and 500ms page loads doesn't move the conversion needle for a store selling artisanal candles.
Isolated instances instead of multisite. Each store gets its own containerized WordPress environment. No shared resources, no noisy neighbors, predictable performance. This is actually what I ended up building with Megify — every generated site runs in its own isolated environment.
Let AI handle the content generation. Back then, we had to manually create templates and sample content for each store type. Today, AI generates unique designs, copy, and product structures from a text description. The provisioning that took us hours of template work now takes minutes.
The lesson
The project wasn't a failure. One client is still happily using it years later. We learned Docker orchestration, headless WordPress architecture, API optimization, and build pipeline management. All of that knowledge directly informed what I'm building now.
But the business model was flawed because we didn't do the infrastructure math until we'd already built the platform. By then, we were emotionally invested in the architecture and kept trying to make it cheaper instead of asking whether headless was the right approach for the market we were targeting.
The takeaway: run the unit economics before you write the first line of code. Especially for platform businesses where infrastructure costs scale with usage. The most elegant architecture in the world doesn't matter if you can't charge enough to pay for the servers.
I'm now building Megify, which evolved directly from that failed platform — even the name comes from MegiCart, the original headless project. Megify generates WordPress sites and ecommerce stores using AI. Traditional WordPress, not headless — because the infrastructure math works. Each site is isolated (not multisite), AI handles the content generation, and the hosting cost per site is predictable and sustainable. There's a technical breakdown of the architecture if you're curious how it works under the hood.
I also open-sourced a tool we built along the way: Figma to Avada — converts Figma designs to WordPress/Avada shortcodes using AI.
Sometimes the boring architecture is the right architecture.
If you've had similar experiences — building something technically impressive that didn't survive contact with business reality — I'd love to hear about it.
Top comments (0)