Building ecommerce from scratch — no framework, no platform, pure custom code — costs $150,000–$500,000 and takes 12–18 months. Most businesses that go that route spend the first year just replicating features that Medusa.js already ships with. The question isn’t whether custom is better. It’s whether you need to build the commerce engine, or just the differentiated experience on top of it.
What “Building Custom” Actually Means
A lot of agencies say “custom ecommerce” when they mean “Shopify with a custom theme.” That’s not what we’re talking about here.
True custom ecommerce means writing your own cart logic, order management, product catalog, inventory rules, checkout flow, discount engine, and payment processing — from scratch. No third-party commerce platform underneath. Your team owns every line.
The legitimate reasons to go fully custom:
- Your commerce logic is so unusual that no existing platform supports it (think: auction mechanics, multi-party marketplaces with complex escrow, or commodity trading with live pricing)
- You’re at a scale where platform fees plus customization costs exceed the cost of ownership for a custom system ($10M+ GMV annually is where this math sometimes starts to change)
- You have a permanent in-house engineering team of 8+ who will maintain it indefinitely
If none of those apply, you’re probably not a candidate for fully custom ecommerce.
What Medusa.js Gives You Pre-Built
Medusa is an open-source headless commerce framework. It ships with the core commerce engine already built: product management, cart, orders, customers, discounts, payment providers, fulfillment providers, and a REST API to tie it all together. The license is MIT — you own it entirely.
What that means in practice: the commerce engine that would cost $100,000–$200,000 to build from scratch is already there. You’re building the storefront, the integrations, and the business logic specific to your operation — not reinventing cart math.
For a detailed breakdown of how Medusa’s architecture works under the hood, see Medusa.js architecture explained.
What Medusa Doesn’t Give You
Medusa has no hosted infrastructure. No built-in analytics dashboard. No drag-and-drop storefront builder. No phone support.
You’re writing the frontend yourself (typically Next.js). You’re deploying on your own infrastructure (Railway, Render, AWS, or similar). You’re connecting analytics yourself (GA4, Segment, Mixpanel — your choice). If something breaks, your developers fix it.
That’s not a flaw. It’s a trade. You get full ownership and zero per-transaction fees. You give up hand-holding and convenience.
The Real Cost of Building From Scratch
Here’s what fully custom ecommerce actually costs — not what agencies quote you in discovery calls, but what it costs when the project is done.
Initial build — $150,000 to $500,000+ A competent team building custom ecommerce from scratch: 1 architect, 2–3 backend engineers, 1–2 frontend engineers, QA, and a project manager. At US market rates, that’s $150–$250/hour loaded. A 12-month project runs $150,000 at minimum. Ambitious builds hit $500,000 before the first sale.
Ongoing maintenance — $8,000–$25,000/month Custom systems need engineers who know the codebase. You’re either keeping that team on retainer or hiring in-house. Security patches, dependency updates, performance optimization, and feature development don’t pause because you launched.
Time to first sale — 12–18 months Most businesses that go fully custom spend the first 6 months on core commerce infrastructure. Cart, checkout, payment processing, order management. They don’t start building the differentiated features until month 7 or 8. Revenue doesn’t start until month 12–18.
At a $1M/year GMV run rate, 12 extra months offline is $1M in lost revenue — before you’ve spent a dollar on development.
The Medusa.js Build Cost (Honest Numbers)
A production Medusa.js store typically costs $50,000–$150,000 to build, depending on complexity.
Here’s what drives that range:
- Storefront complexity — A standard Next.js storefront using Medusa’s starter kit runs $20,000–$40,000. A fully bespoke storefront with custom animations, product configurators, or unusual UX patterns runs $50,000–$80,000.
- Integration count — Each third-party integration (ERP, 3PL, custom payment provider, loyalty platform) adds $5,000–$15,000. Budget 10–15% of your build cost per major integration.
- Custom commerce logic — Subscription billing, B2B pricing tiers, multi-warehouse rules, complex tax logic. Each adds $10,000–$30,000 depending on depth.
The time to first sale is 3–6 months for most builds. That’s 6–12 months faster than fully custom — which is real money if you’re sitting on inventory waiting to sell.
For a broader comparison of how Medusa stacks up against other open-source headless platforms, see open-source headless commerce comparison.
When Medusa Wins the Argument
You need checkout customization Shopify can’t deliver. Medusa’s checkout is pure code you own. Multi-step checkout flows, custom validation logic, unusual payment sequences — it all goes in your codebase, not a locked-down hosted page. We cover this in depth in our post on Medusa.js checkout customization.
You’re migrating off Shopify. If you’ve hit Shopify’s ceiling on checkout customization, API rate limits, or transaction fee math, Medusa is the most direct path to full ownership without rebuilding everything. See when to migrate from Shopify to headless.
You want zero per-transaction platform fees. Shopify charges 0.5–2% per transaction if you’re not using Shopify Payments, on top of your monthly plan. At $500K GMV, that’s $2,500–$10,000/year in pure platform tax. At $2M GMV, it’s $10,000–$40,000. Medusa takes nothing.
Your catalog or order logic is unusual, but not alien. B2B pricing tiers, multi-warehouse fulfillment, subscription bundles — Medusa handles these with extensions. Fully custom would require building the engine before you can even touch the logic.
When Custom Ecommerce Actually Makes Sense
Medusa isn’t the right answer for everyone. There are legitimate cases for going fully custom.
You’re building a marketplace, not a store. If you have sellers and buyers, escrow mechanics, and revenue splits on every transaction — that’s not a commerce store, that’s a platform. Medusa isn’t designed for that architecture. You need something built for it.
Your commerce logic has no analog. Live auction clearing prices. Dynamic slot availability for service bookings. Commodity pricing tied to an external feed with real-time updates. If Medusa’s extension model would require rewriting the core to make your logic work, you’ve outgrown it.
You’re at $10M+ GMV and platform savings justify the build. At significant scale, the math on custom ownership can work. But be honest: the ongoing engineering cost often exceeds what you’d save on platform fees unless you’re at $20M+ GMV with a team already in place.
Medusa vs Custom: The Decision Framework
| Factor | Medusa.js | Fully Custom |
|---|---|---|
| Initial cost | $50K–$150K | $150K–$500K+ |
| Time to first sale | 3–6 months | 12–18 months |
| Commerce engine | Pre-built, owned | Built from scratch |
| Customization ceiling | Very high (open source) | Unlimited |
| Ongoing dev cost | $3K–$8K/month | $8K–$25K/month |
| Per-transaction fees | $0 | $0 |
| Best for | Differentiated stores, Shopify migrations | Platforms, alien commerce logic |
If you can build on top of Medusa rather than below it, you almost always should. The commerce engine is a solved problem. The differentiated experience is not.
What This Means for Your Build Budget
If you have $150,000 to spend on ecommerce, you have a choice: spend it building a commerce engine no one will see, or spend $60,000 on a Medusa build and put $90,000 into the differentiated experience — the storefront, the integrations, the custom logic that actually drives conversion.
That $90,000 pays for 3–4 months of ongoing development after launch. It pays for proper analytics setup, A/B testing, performance optimization, and feature iteration. A custom-from-scratch build with the same $150,000 budget gives you a cart that works. Maybe.
For growing ecommerce businesses specifically evaluating Medusa for their next phase, see Medusa.js for growing ecommerce.
The Developer Equation
This point gets glossed over in most Medusa comparisons, and it shouldn’t.
Medusa requires a developer. Not at launch — indefinitely. Security updates, dependency upgrades, bug fixes, and feature additions are your team’s responsibility for as long as the store runs. On Shopify, Shopify’s engineers maintain the platform infrastructure. On Medusa, your engineers do.
For fully custom ecommerce, this is already the assumption — you’ve accepted permanent engineering ownership from day one. For a business moving from Shopify to Medusa, this shift is significant. You’re taking on infrastructure responsibility you didn’t have before.
The developers you need for Medusa are not the same as WordPress developers. Medusa is Node.js and TypeScript on the backend. The storefront is React and Next.js. PostgreSQL for the database. If your existing developer runs WordPress sites, they are not ready for a Medusa build without training.
Plan for either a dedicated agency retainer ($2,000–$5,000/month for maintenance + minor feature work) or an in-house hire. The “hire a developer once to build it and never touch it again” model does not work for a production Medusa store.
Fully custom ecommerce has the same developer requirement — at 3–4x the cost, because the codebase is entirely proprietary and larger. Medusa’s open-source foundation means your developer can look up how it works. A fully custom system means your developer has to know it from memory or re-read the code every time.
The Ownership Argument
Both Medusa and fully custom ecommerce give you full code ownership. The difference is what you own.
With Medusa, you own a production-grade commerce engine (the Medusa backend), plus the custom code you’ve written on top of it (storefront, integrations, business logic). The commerce engine was built and tested by Medusa’s team and the open-source community — you’re inheriting quality.
With fully custom ecommerce, you own everything: the commerce engine included. The quality of that engine is entirely a function of how well your development team built it and how thoroughly it was tested. Some teams build excellent custom systems. Some build fragile ones that break at scale. There is no community of 10,000 developers who have stress-tested your custom cart logic.
For most businesses, the right question is: what advantage do I get from owning the commerce engine specifically? If the answer is “none — we just need a cart that works and a checkout we control,” Medusa gives you that. If the answer is “our cart logic is so unusual that no existing engine can model it,” that’s the rare case where custom makes sense.
FAQ
Is Medusa.js suitable for a business that has never had a developer on staff? No. Medusa requires a developer to build, deploy, and maintain. It has no hosted admin panel you can run yourself — it needs a technical team. If you don’t have developers and don’t plan to hire or contract them, Shopify or WooCommerce are more appropriate starting points.
Can you start on Medusa and migrate to fully custom later? Yes, and the migration path is cleaner than migrating from a hosted platform. Because Medusa is API-first, you can replace the commerce engine piece by piece without taking the storefront down. Most teams who outgrow Medusa fork it rather than replace it.
How does Medusa compare to WooCommerce for a custom build? WooCommerce is better suited for content-heavy stores where WordPress integration matters (blogs, editorial, membership sites layered with ecommerce). Medusa is better suited for pure ecommerce where performance, checkout control, and API-first architecture are the priority. See Medusa.js vs WooCommerce for the full comparison.
What kind of developer do you need to build on Medusa? A Node.js/TypeScript backend developer for the Medusa server, and a React/Next.js developer for the storefront. You need at least one person who’s comfortable with Docker and PostgreSQL for infrastructure setup. This is not a WordPress developer skillset — plan accordingly when hiring.
What happens if Medusa.js stops being maintained? Because Medusa is MIT-licensed open source, your code doesn’t disappear if the project goes dormant. The codebase lives on your infrastructure. You fork it, maintain it, and continue. This is a meaningful advantage over hosted platforms where a pricing change or shutdown is entirely out of your hands.
Is Medusa.js vs custom ecommerce the right question if we’re currently on Shopify? Probably not. If you’re on Shopify and considering a move, the real question is whether Medusa’s capabilities solve the specific limitations you’ve hit — checkout lock-in, API limits, transaction fees, or catalog complexity. We cover that directly in Medusa.js vs Shopify.
If you’re evaluating a Medusa build and want honest numbers specific to your project scope, see our fixed-price packages or talk through the requirements with us directly. We build on Medusa when it’s the right tool. We’ll tell you when it isn’t.