How to Build an E-Commerce Platform Like Shopify: The Architecture Guide
- Ashit VoraBuild & ShipLast updated on
Summary
To build an e-commerce platform like Shopify, you need: multi-tenant merchant architecture, a storefront builder (templated or drag-and-drop), product catalog management, order management, payment processing, and an app/plugin marketplace. An MVP takes 20-30 weeks and costs $150K-$350K. Multi-tenancy, payment infrastructure, and the storefront theme system are the most complex engineering problems.
Key Takeaways
Multi-tenancy is the foundational architecture decision: each merchant gets their own isolated data environment while sharing infrastructure. Database isolation strategy (shared schema vs. separate schemas) affects scalability and compliance.
The storefront builder (theme system) is the most visible differentiator but also one of the most complex pieces to build. Liquid-style templating or a visual builder both require significant front-end infrastructure.
Payments are more complex than a direct checkout: platform fee collection, merchant payout scheduling, refund and chargeback handling, and tax calculation all require careful design.
If you are building a vertical e-commerce platform (for a specific industry), the business model is usually: platform fee on transactions + monthly subscription. Define this before building.
The Shopify app store model -- third-party developers extending the platform -- is not a v1 feature. Build a stable API first, then open it to partners.
Shopify built a $100 billion business by making e-commerce infrastructure available to any business that needed it. That did not happen because Shopify built everything -- it happened because they built a platform extensible enough for others to build the rest.
If you are building a vertical e-commerce platform -- for a specific product category, a specific business model (wholesale, subscription, rental), or a specific geography where Shopify's payment coverage or language support is insufficient -- the engineering is real and substantial.
This guide covers the architecture.
What you are actually building
A Shopify-equivalent is a SaaS platform for merchants. It is not a single e-commerce store. The layers:
Merchant portal: The admin interface where merchants manage their products, orders, customers, and settings.
Storefront layer: The customer-facing shop, either from a template the merchant configures or a custom build. This is what shoppers interact with.
Commerce engine: The backend logic for inventory, pricing, discount rules, tax calculation, and checkout.
Payment infrastructure: The integration layer between merchants, payment processors, and your platform fee collection.
Analytics: Sales data, traffic, conversion rates, and customer insights for merchants.
This is more than one app. It is a suite of interconnected products.
Multi-tenancy: The foundational decision
The first architecture decision: how do you isolate merchant data?
Row-level isolation (most common): All merchants share the same database tables. Every row has a merchant_id column. All queries filter by merchant_id. Simple to build and operate, scales well with proper indexing.
Schema-level isolation: Each merchant has their own database schema within a shared database server. Higher isolation, easier to run per-merchant backups and migrations, but more complex to operate.
Database-level isolation: Each merchant gets their own database. Maximum isolation, simplest compliance story, but expensive to operate at scale.
For most platforms: row-level isolation. Implement database-level isolation only if you have enterprise compliance requirements (HIPAA, SOC2) that demand it.
The storefront layer
This is what differentiates your platform visually, but it is also one of the most complex pieces to build.
Templated storefronts: Pre-built theme options that merchants can configure (colors, fonts, logo, layout). Merchants cannot code; they configure. This is Shopify's original model and covers 80% of merchant needs. Requires a theme template system (Liquid-style templating or React-based with configuration injection).
Drag-and-drop builder: Visual storefront builder where merchants rearrange blocks. Much higher development cost (you are building a visual editor), but more self-service. Webflow-style block editors are the modern reference point.
Headless commerce: Your platform provides APIs; merchants bring their own front-end. B2B and enterprise merchants prefer this. Requires clean, comprehensive APIs and good documentation.
For v1: templated storefronts with 3-5 themes. Add drag-and-drop later.
The commerce engine
The business logic layer that makes the platform work:
Product catalog: Products, variants (size, color, material), inventory levels per variant, images, and pricing. Handle physical products, digital products, and services differently.
Inventory management: Track stock per variant, per location if the merchant has multiple warehouses. Reserve inventory at checkout; decrement on order fulfillment.
Pricing and discounts: Base price, sale price, percentage discounts, fixed amount discounts, and coupon codes. Discount stacking rules (can a customer use a coupon and a sale price together?) need explicit rules.
Tax calculation: The regulatory nightmare. Tax rates vary by product category, merchant location, and customer shipping address. For US merchants, integrate TaxJar or Avalara. For international, it gets more complex. Do not build tax calculation logic from scratch.
Checkout: The most important user flow. Shipping address, shipping method selection (with rates from your carrier integration), payment, and order confirmation. The checkout conversion rate is the primary metric that determines merchant success -- and their satisfaction with your platform.
Payment infrastructure
Stripe Connect is the standard architecture for platforms.
How it works:
- Merchant creates a Stripe Connect account during onboarding
- Your platform is the primary Stripe account
- Customer payments are captured through your platform
- Your platform fee is deducted automatically
- The remainder is transferred to the merchant's connected account on your payout schedule
Key implementation areas:
Onboarding KYC: Stripe requires merchants to submit identity and business information before they can receive payouts. Build a smooth onboarding flow for this.
Payout schedules: Daily, weekly, or monthly -- configurable. The merchant needs visibility into pending payouts.
Refund handling: When a customer returns an item, the refund comes from the merchant's connected account. You may need to refund your platform fee as well (business decision).
Chargeback management: Stripe handles chargeback disputes, but you need to notify the merchant and freeze funds during the dispute period.
Order management
After checkout, the order enters a lifecycle:
- Placed -- payment captured
- Processing -- merchant acknowledges and begins fulfillment
- Shipped -- tracking number added, customer notified
- Delivered -- tracking confirms delivery
- Completed -- no further action required
Returns and refunds require a separate flow. Merchants need: the order list view, order detail view, fulfillment actions, and refund initiation. Customers need: order confirmation email, shipping notification with tracking, and order history in their account.
Integrations your merchants need
No e-commerce platform works in isolation. Required integrations for day one:
Shipping carriers: UPS, FedEx, USPS, DHL rate APIs for live shipping quotes at checkout
Email: Order confirmation, shipping notifications, and marketing emails (Mailchimp, Klaviyo, or Postmark for transactional)
Analytics: Google Analytics 4 for storefront traffic
Social: Facebook Pixel and TikTok Pixel for ad conversion tracking
What to skip in v1
App marketplace (third-party developers)
POS (point of sale) for physical retail
B2B wholesale pricing
Subscription billing for merchants (add after launch)
Advanced analytics and reporting
Multi-currency and international shipping in v1 (unless this is your vertical)
Tech stack
| Layer | Choice |
|---|---|
| Merchant portal | React + Next.js |
| Storefront | Next.js (SSG/ISR for performance) |
| Backend | Node.js |
| Database | PostgreSQL |
| Payments | Stripe Connect |
| Tax | TaxJar API |
| Postmark (transactional) + Mailchimp (marketing) | |
| Search | Elasticsearch (product search) |
| Storage | AWS S3 + CloudFront |
| Hosting | AWS ECS or Vercel |
Cost to build
| Scope | Timeline | Cost |
|---|---|---|
| MVP (merchant portal, storefront, checkout, orders) | 20-30 weeks | $150K-$350K |
| With drag-and-drop storefront builder | Add 12-16 weeks | Add $100K-$180K |
| With app marketplace API | Add 8-12 weeks | Add $60K-$100K |
The real question: Why not just use Shopify?
If your merchants can use Shopify, they should. Shopify has 15 years of commerce infrastructure, a 10,000-app ecosystem, and best-in-class checkout conversion.
Build a custom platform when:
Your vertical has compliance or data requirements Shopify cannot meet (medical supplies, regulated goods)
Your business model requires transaction economics Shopify does not support (wholesale, auctions, rental)
Your geography requires payment or language support Shopify cannot provide
You are building for a specific industry workflow that requires deep integration (event ticketing, food service, B2B purchasing)
These are real use cases. We build them regularly.
If you are building a vertical commerce platform for a specific business model, let's talk about the architecture.
Frequently Asked Questions
- An MVP with merchant signup, product catalog, storefront, checkout, and basic order management takes 20-30 weeks with a team of 5-8 developers. A production-grade platform with theme customization, app extensions, advanced analytics, and enterprise features takes 12-18 months. Building a Shopify equivalent at full scale is a multi-year effort -- most vertical platforms win by going deep on a specific vertical, not broad.
- MVP development: $150K-$350K. Monthly operating costs depend on merchant count and transaction volume. Infrastructure costs are relatively predictable (multi-tenant hosting scales with merchant count). The payment processing layer is where variable costs accumulate: 0.5-2% platform fee on transactions is typical, and collecting it requires Stripe Connect or similar split payment architecture.
- Multi-tenancy means one platform installation serves many merchants, each with isolated data. Shopify serves millions of merchants on shared infrastructure -- each merchant's products, orders, and customer data are logically isolated but physically co-located. The isolation strategy matters: row-level isolation (all tenants in the same tables, filtered by tenant ID) is simplest and most common. Schema-level isolation (each tenant has their own database schema) is more expensive but easier for compliance. Database-level isolation (each tenant gets a separate database) is most isolated but operationally expensive.
- Stripe Connect is the standard architecture for platform payments. Merchants onboard to Stripe Connect as connected accounts. Customer payments flow through your platform account. You collect your platform fee and pass the remainder to the merchant's connected account. Payout schedules, refund handling, and chargeback responsibility are configurable in Stripe Connect. This architecture handles: platform fee collection, merchant payouts, cross-merchant refunds, and chargeback management.
- Standard SaaS e-commerce platform models: subscription fee (monthly fee per merchant, tiered by GMV or feature set) plus transaction fee (percentage of GMV processed through the platform). Shopify charges both. For vertical platforms, a simpler model often works: flat subscription covering all features, no transaction fee, revenue from value-added services (shipping integration, marketing tools, analytics).
