The Problem: Beautiful Personalization That Doesn’t Scale
Personalized ecommerce is powerful, until you’re manually creating shop #437 this month.
Rapid Data, a European provider of digital funeral services, had a vision: every funeral ceremony should have its own dedicated online flower shop. Tailored products. Ceremony-specific. Respectful checkout experience. Automatically integrated with their industry ERP.
The reality they faced:
- Each shop required up to 1 hour of manual setup
- Product catalogs needed custom curation per ceremony
- 1,000 ceremonies = 1,000 hours of repetitive work
- Human error crept into sensitive customer moments
- Their existing platform couldn’t handle event-based commerce at scale
Shopify? Not built for this. WooCommerce? Same problem. Enterprise platforms? Either too rigid or $200K+ to customize.
They needed infrastructure that treated events as first-class citizens, not bolt-on features.
The Challenge: Context-Driven Commerce Requires Different Architecture
Traditional ecommerce platforms assume one core problem: selling products to anyone, anytime.
Event-based commerce is fundamentally different: selling specific products to specific people at specific moments.
For Rapid Data, every transaction was tied to:
- A unique funeral ceremony
- A specific date and location
- Families in emotionally sensitive moments
- Real-time ERP coordination (flowers don’t wait)
What they actually needed:
- Automated storefront creation triggered by ERP events
- Ceremony-specific product assortments (not global catalogs)
- Seamless two-way ERP synchronization
- Zero manual setup per event
- Scalability to thousands of concurrent shops
No off-the-shelf platform could deliver this. They needed custom infrastructure.
Our Approach: Event-Driven Multi-Storefront Architecture
We’ve built ERP-integrated commerce systems for healthcare, manufacturing, and now funeral services. The pattern is similar: legacy platforms breaking under contextual commerce requirements.
The Architecture We Designed
Trigger: Funeral event created in ERP
↓
Automated Response: New storefront generated automatically
↓
Storefront Contains:
- Ceremony-specific product catalog
- Pre-configured checkout flow
- Tailored messaging and branding
- Direct ERP order sync
Result: Family sees a simple, dedicated shop. Behind the scenes, zero human intervention.
Why Medusa Was the Foundation
We chose MedusaJS for three specific reasons:
1. API-First Architecture
Medusa doesn’t assume your frontend, your workflows, or your data structure. We controlled everything.
2. Multi-Storefront Native
Built-in support for region/currency/catalog logic that we extended for event-based contexts.
3. ERP Integration Flexibility
No proprietary APIs to fight. We built exactly the integration Rapid Data’s ERP required.
What this meant in practice:
- Event data from ERP → triggers storefront creation via Medusa API
- Product assortment rules → programmatically assigned per ceremony
- Order data → synchronized back to ERP in real-time
- No templates. No “close enough.” Exact workflows.
The Implementation: Building for Sensitive, Regulated Operations
This wasn’t a typical ecommerce build. Funeral services are:
- Highly regulated (data privacy, payment processing)
- Emotionally sensitive (no room for checkout errors)
- Time-critical (flowers for Thursday’s ceremony don’t help on Friday)
Phase 1: Core Multi-Storefront System (8 Weeks)
Delivered:
- Event-triggered storefront generation
- Automated product catalog assignment
- Ceremony-specific checkout flows
- Basic ERP synchronization
Phase 2: Stability & Integration Refinement (6 Weeks)
Delivered:
- Bi-directional ERP sync (orders, inventory, fulfillment)
- Error handling for edge cases (duplicate events, cancellations)
- Performance optimization (sub-2-second storefront generation)
- Admin dashboard for operational visibility
Phase 3: Scale Preparation (Ongoing)
Delivered:
- Load testing for 10,000+ concurrent storefronts
- Monitoring and alerting infrastructure
- Documentation for Rapid Data’s team
- Continuous refinement based on real-world usage
The Results: From 847 Manual Hours to Zero
Before: Manual Setup Model
- 50+ minutes per storefront (product selection, configuration, QA)
- 847 hours per 1,000 ceremonies (over 20 full-time work weeks)
- High error risk (wrong products, pricing mistakes in sensitive moments)
- Scaling impossible (hitting operational capacity at ~500 ceremonies/month)
After: Automated Event-Based System
- <2 seconds per storefront (fully automated)
- Zero manual hours per 1,000 ceremonies
- Consistent experience (no human error in product catalogs or pricing)
- Unlimited scale (architectural limit: 50,000+ concurrent storefronts)
Business Impact
Operational Cost Savings:
847 hours × average EU operational salary = ~€25K saved per 1,000 ceremonies
Speed to Market:
Funeral booked → shop live: <5 minutes (was 24-48 hours with manual setup)
Customer Experience:
Families receive shop link immediately in booking confirmation. No waiting. No delays.
Scalability:
System now handles peak loads of 200+ new ceremonies per day. Previous limit: ~15/day.
What Makes Event-Based Commerce Different (And Why Most Platforms Fail At It)
Traditional ecommerce platforms are built around these assumptions:
- One store selling to many customers
- Static product catalogs
- Persistent shopping experiences
Event-based commerce inverts all of this:
- Many stores (one per event) serving targeted audiences
- Dynamic, context-specific catalogs
- Ephemeral shopping experiences (shop exists for ~2 weeks)
Why existing platforms struggle:
- Shopify: Not designed for programmatic store creation
- WooCommerce: Multi-site architecture collapses at scale
- BigCommerce/Salesforce: Enterprise pricing for custom development you don’t fully own
- Custom PHP builds: Maintenance nightmare, scaling issues
What actually works:
- Headless architecture (Medusa, commercetools, custom)
- Event-driven design patterns
- Deep ERP integration from day one
- Infrastructure you own and control
Beyond Funeral Services: Where Event-Based Commerce Applies
This architecture pattern works for any industry where commerce is tied to specific contexts:
✅ Healthcare: Patient-specific medical supply stores
✅ Education: Course-specific bookstores and materials
✅ Events & Conferences: Attendee-specific merch and materials
✅ B2B Manufacturing: Project-specific parts catalogs
✅ Real Estate: Property-specific service marketplaces
✅ Hospitality: Reservation-specific upgrades and services
The common thread: commerce that must adapt to specific contexts automatically, at scale.
The DBot Software Approach: Architecture First, Implementation Second
We’ve been building custom ecommerce platforms since 2018. We’ve seen the pattern:
Stage 1: Business outgrows SaaS (Shopify, BigCommerce, etc.)
Stage 2: Tries to force-fit SaaS with plugins/apps
Stage 3: Realizes they need custom infrastructure
Stage 4: Finds us (or builds in-house and regrets it 18 months later)
What we do differently:
1. We Architect Before We Build
Most agencies start coding immediately. We spend week 1 mapping:
- Your existing ERP/system workflows
- Your actual business logic (not idealized versions)
- Your operational pain points
- Your scaling requirements
Result: Builds that fit your business, not generic ecommerce templates.
2. We Build for Operations, Not Just Launch
Pretty demos are easy. Systems that run reliably in regulated industries for 3+ years? That requires different thinking.
We focus on:
- Error handling for edge cases
- Monitoring and observability
- Clear documentation
- Handoff to your team (you should own this, not depend on us)
3. We Use Modern Frameworks (Not Custom Everything)
Medusa gives us 60% of ecommerce infrastructure out-of-the-box. We focus our custom development on your differentiation:
- Your unique workflows
- Your ERP integration
- Your business logic
- Your operational requirements
Result: 2-4 month builds instead of 12-18 months.
The Technology Stack (For Technical Decision-Makers)
Core Platform:
- Medusa.js (Node.js-based headless commerce)
- PostgreSQL (primary database)
- Redis (caching & job queues)
Frontend:
- Next.js (React framework)
- TypeScript (type safety across codebase)
- Tailwind CSS (rapid UI development)
ERP Integration:
- Custom REST API middleware
- Event-driven sync via message queues
- Bi-directional data flow (orders, inventory, fulfillment)
Infrastructure:
- Containerized deployment (Docker)
- Kubernetes orchestration
- Automated CI/CD pipeline
- Monitoring: Datadog + custom dashboards
Why This Stack:
- Modern, maintainable codebase
- Active open-source communities
- Scales to 10,000+ storefronts
- Your team can hire for these technologies (not proprietary frameworks)
Is Event-Based Commerce Right for Your Business?
You probably need this if:
✅ Your commerce is tied to specific events/contexts (not general catalog selling)
✅ You’re creating 50+ unique shopping experiences per month
✅ Manual setup is killing your operational team
✅ Your existing platform can’t handle contextual commerce
✅ You need deep ERP/system integration (not surface-level APIs)
✅ You’re paying $40K+/year for platforms that still require manual work
You probably don’t need this if:
❌ You’re selling standard products to general audiences
❌ One storefront serves all your needs
❌ Your existing platform works fine with minor customization
❌ You’re pre-revenue or very early stage
❌ You don’t have technical resources for basic maintenance
What We’ve Learned Building Event-Based Commerce
1. ERP Integration Is 40% of the Work
Don’t underestimate this. Legacy ERP systems are rarely documented well, APIs are inconsistent, and edge cases appear in production.
Budget accordingly. If someone quotes you an event-based system without deep ERP discovery, they’re underestimating.
2. Operational Edge Cases Matter More Than Features
The hard part isn’t creating storefronts. It’s handling:
- What happens when a ceremony is cancelled?
- What if the ERP sends duplicate events?
- How do you handle partial refunds across multiple ceremonies?
- What monitoring do operators need to catch issues?
This is where experience matters. We’ve built enough of these systems to know the edge cases before they bite you.
3. Start With One Event Type, Then Expand
Rapid Data started with funeral flowers only. Now they’re expanding to:
- Condolence cards
- Memorial donations
- Service recordings
- Tribute videos
The infrastructure scales. Once event-based architecture is in place, adding new commerce types is straightforward.
Ready to Stop Manual Store Creation?
If you’re manually creating shops, managing hundreds of SKUs across contexts, or fighting your platform to support event-based commerce, let’s talk.
We offer a free 60-minute Architecture Review:
We’ll review:
- Your current manual workflows
- Your ERP/system landscape
- Your scaling requirements
- Whether custom infrastructure makes sense (honest recommendation)
No sales pressure. No generic pitch. Just experienced guidance from a team that’s solved this problem before.
Schedule Your Free Architecture Review HERE!
