10 Real Agency Scenarios: When Litestore Beats Medusa (And Vice Versa)

Every agency has been here: client wants a new commerce build, you need to pick the stack. The architecture diagrams look similar. The feature lists overlap. But when you're deep in a sprint and the client changes scope, the differences become painfully clear.

Here are 10 real scenarios we've encountered — and how each platform actually performs.

Scenario 1: Flash Sale Block with Inventory Awareness

Client request: "We want a flash sale block that shows different products based on inventory and disappears when stock runs out."

Medusa Approach

1. Create a promotion in the admin dashboard
2. Build a custom storefront component to display it
3. Set up inventory webhooks or poll the API
4. Write client-side logic to hide when products sell out
5. Debug cache invalidation when block shows sold-out items
6. Add error handling for race conditions

Time: 2-3 days Team: Frontend dev + backend understanding

Litestore Approach

1. Create a Spot with curation binding
2. Enable inventory-aware cascade (built-in)
3. Spot auto-suppresses when curation inventory depletes
4. Fallback cascade shows next promotion automatically

Time: 30 minutes in admin Team: Marketing operator, no dev needed

Winner: Litestore. The Spot primitive with cascade fallbacks solves this at the architecture level.

---

Scenario 2: Homepage A/B Testing

Client request: "We want to test two different product arrangements on the homepage."

Medusa Approach

1. Integrate third-party A/B testing tool (LaunchDarkly, Optimizely, etc.)
2. Create two curation variants in the CMS or database
3. Write user bucketing logic in the storefront
4. Track conversions manually or through analytics platform
5. Build admin UI to view results

Time: 1-2 weeks Cost: $300-2000/month for A/B platform

Litestore Approach

1. Create a StoredFeed with two variants
2. Set traffic allocation (e.g., 50/50)
3. Deterministic user bucketing happens automatically
4. Confidence decay tracks performance over time
5. View results in existing admin dashboard

Time: 1 hour Cost: $0 additional

Winner: Litestore. Stored Feed with A/B variants is a first-class feature.

---

Scenario 3: Multi-Warehouse Inventory

Client request: "We have 3 warehouses and need real-time inventory sync with different shipping rules per region."

Medusa Approach

1. Stock Location module handles multiple warehouses (built-in)
2. Fulfillment module with provider plugins routes orders
3. Inventory module tracks per-location stock
4. Sales Channel module for regional storefronts
5. Tax module handles regional compliance

Time: 2-3 days configuration Documentation: Extensive, well-tested patterns

Litestore Approach

1. Single-store architecture assumes one location
2. Would need schema changes for multi-location
3. No fulfillment provider abstraction exists
4. Regional tax/shipping would need custom development

Time: 2-4 weeks of architectural work

Winner: Medusa, decisively. Multi-location inventory is a solved problem in their module system.

---

Scenario 4: Marketing Self-Service

Client request: "The marketing team wants to update promo blocks without asking developers."

Medusa Approach

1. Admin dashboard handles products and orders
2. Visual merchandising requires headless CMS integration
3. Marketing edits CMS → storefront fetches → displays
4. New block types still need developer involvement
5. Coordination between systems for campaign timing

Result: Marketing can edit content, but not merchandising logic.

Litestore Approach

1. Spots are visual merchandising primitives
2. Operators create/edit blocks directly in admin
3. CardType, placement, schedule — all configurable in UI
4. Stats enrichment pulls live data automatically
5. Cascade ensures something always displays

Result: Marketing controls the full merchandising experience.

Winner: Litestore. Spots were designed for operator self-service.

---

Scenario 5: Marketplace Build

Client request: "We're building a marketplace where vendors manage their own products."

Medusa Approach

1. Multi-tenant architecture from the start
2. Sales Channels isolate vendor storefronts
3. RBAC module for vendor permissions
4. Stock Location per vendor warehouse
5. Order module handles split fulfillment
6. Payment module manages vendor payouts

Time: 2-4 weeks Pattern: Well-documented, community-proven

Litestore Approach

1. Single-store architecture at the core
2. Would need: vendor model, scoped queries, permission system
3. Split checkout flow required
4. Payout tracking system needed
5. Essentially rebuilding core assumptions

Time: 2-3 months of architectural work

Winner: Medusa, by a mile. Marketplaces need multi-tenancy at the foundation.

---

Scenario 6: Contextual Product Badges

Client request: "Show 'Trending', 'Low Stock', 'New Arrivals' badges on products — but contextually appropriate, not everywhere."

Medusa Approach

1. Add badge fields to product model
2. Write logic to compute which badges apply
3. Decide in storefront which to display
4. No coordination between products on a page
5. Risk: 50 products all showing "SALE" badges

Result: You get badges, but no merchandising intelligence.

Litestore Approach

1. Product Signals are computed from state automatically
2. SignalContext determines what shows where:
   • sale_curation → only discount signals
   • feed → diverse signals (prevents repetition)
   • product_page → all relevant signals
3. Priorities determine which signal wins
4. Eligibility functions are deterministic and explainable

Result: Signals are orchestrated, not just displayed.

Winner: Litestore. Signal contexts solve the "everything has a badge" problem.

---

Scenario 7: Platform Migration

Client request: "We need to migrate from our legacy platform. 10,000 products."

Medusa Approach

1. Official migration plugins available for major platforms
2. Well-documented data mapping
3. Community has done this thousands of times
4. Product, variant, curation, customer migration covered
5. Order history import supported

Time: 1-2 days for standard migration

Litestore Approach

1. Use CSV import for structured data
2. Map external schema to Prisma schema with import adapters
3. Handle variant/option model differences
4. Test extensively with production data
5. Custom JSON import for complex data

Time: Depends on data complexity

Winner: Medusa. Ecosystem matters for migrations.

---

Scenario 8: Real-Time Product Urgency

Client request: "The product page needs to show 'X people are viewing this' and 'Only 3 left'."

Medusa Approach

1. "Only 3 left" — query inventory module, display conditionally
2. "X people viewing" — need real-time infrastructure:
   • WebSocket server setup
   • Redis pub/sub for viewer tracking
   • Custom storefront integration
3. Two separate systems with separate caches

Time: 3-5 days for live viewers

Litestore Approach

1. "Only 3 left" — low_stock Signal (built-in, computed at read time)
2. "X viewing" — live-viewers component exists
3. Signals resolve automatically from product state
4. Single data path, unified caching

Time: Already built. Just enable.

Winner: Litestore. These are product signals, and signals are a primitive.

---

Scenario 9: Multiple Payment Providers

Client request: "We need Stripe, PayPal, and a local payment provider for the Brazilian market."

Medusa Approach

1. Payment module provides abstract interface
2. Stripe plugin (official, well-maintained)
3. PayPal plugin (official)
4. Local provider → write plugin following the interface
5. Checkout flow handles multiple providers elegantly
6. Webhooks managed by module

Time: 1 day for official providers, 2-3 days for custom

Litestore Approach

1. Direct Stripe integration exists
2. Adding PayPal requires custom implementation
3. No payment provider abstraction layer
4. Would need to build provider interface first

Time: 3-5 days per additional provider

Winner: Medusa. Payment abstraction is mature and battle-tested.

---

Scenario 10: Event-Driven Integrations

Client request: "When order status changes, trigger email, SMS, and update their ERP system."

Medusa Approach

1. Event Bus emits order.placed, order.shipped, etc.
2. Notification module subscribes and handles email/SMS
3. ERP integration → write a subscriber that listens for events
4. Each handler is independent, loosely coupled
5. Retry logic built into event system
6. Workflow compensation if ERP call fails

Architecture: Event-driven, decoupled, resilient

Litestore Approach

1. afterCreate/afterUpdate hooks in BaseCRUD
2. Call email service directly in hook
3. Call SMS service directly
4. Call ERP API directly
5. If ERP fails... transaction already committed
6. Need to add retry queue manually

Architecture: Synchronous, coupled, simpler

Winner: Medusa. Event Bus with workflows handles distributed failures gracefully.

---

The Scorecard

| Scenario | Medusa | Litestore | Why | | -------------------------- | :----: | :-------: | ------------------------- | | Flash sale with inventory | | W | Spots + cascade fallbacks | | Homepage A/B testing | | W | Stored Feed built-in | | Multi-warehouse inventory | W | | Stock Location module | | Marketing self-service | | W | Spots primitive | | Marketplace build | W | | Multi-tenant foundation | | Contextual product badges | | W | Signal contexts | | Platform migration | W | | Plugin ecosystem | | Real-time urgency signals | | W | Signals + live viewers | | Multiple payment providers | W | | Payment abstraction | | Event-driven integrations | W | | Event Bus + workflows |

Final Score: Medusa 5, Litestore 5

---

The Decision Framework

Choose Medusa when:

• Building for multiple clients — Module system means 80% reuse
• Complex fulfillment — Multi-warehouse, dropshipping, 3PL
• International commerce — Multi-currency, multi-region tax
• Marketplace model — Vendor isolation is architectural
• Enterprise integrations — ERP, PIM, OMS need event decoupling

Choose Litestore when:

• Building one high-value store — Deep customization > modules
• Merchandising is the moat — Spots, feed, signals are unique
• Marketing drives the experience — Operator self-service is core
• Speed to market matters — Server Actions = fast iteration
• Team is React/Next.js native — No separate backend mental model

---

The Uncomfortable Truth

Most agencies default to Medusa because:

• Clients ask for "headless" (it sounds modern)
• It looks safer in proposals
• More Stack Overflow answers exist

But for direct-to-consumer suppliers where merchandising is the competitive advantage, Litestore's architecture solves problems Medusa doesn't even have primitives for.

The Spot → Signal → Feed stack is what you'd build if you started from a sourcing's problems instead of a platform's problems.

Neither is wrong. They're optimized for different futures.

Choose based on the problem you're actually solving, not the problem that sounds most impressive in a pitch deck.