Building Scalable Commerce for Aroma360: Custom Cart, Subscriptions & Multi-Store Architecture
Aroma360 and Hotel Collection, two fast-growing D2C fragrance and wellness brands, needed to scale their ecommerce operations beyond standard Shopify capabilities. As order volumes reached 15,000+ monthly across multiple brands, native platform features became constraints rather than enablers.
This technical blog discusses how custom cart architecture, extended subscription workflows, and multi-store checkout systems enabled Aroma360 to scale operations while maintaining experimentation velocity.
Challenge: Platform limitations restricting personalization, subscription management, and multi-brand expansion
Solution: Custom Rebuy templates, GCP microservices extending Ordergroove, unified checkout architecture
Impact: 32% increase in AOV, 12x faster A/B testing cycles, 40% reduction in operational overhead
The Challenge
Business Context
Aroma360 had grown to process over 15,000 orders monthly across two brand storefronts (Aroma360 and Hotel Collection). While Shopify provided a solid foundation, three specific limitations emerged at scale:
1. Cart Personalization Constraints
The native Shopify cart couldn't support dynamic upsells, subscription upgrades within checkout, or conditional merchandising logic based on cart contents. A/B testing required full theme redeployments, creating 4-week iteration cycles that slowed optimization efforts.
2. Subscription Workflow Complexity
With 8,000+ active subscribers, the operations team spent 40 hours weekly on manual subscription adjustments. Ordergroove handled core subscription features well, but lacked bulk action capabilities and custom workflow support for edge cases (pause, skip, modify delivery schedules).
3. Multi-Brand Management Overhead
Launching Hotel Collection on a separate Shopify instance meant duplicated integrations, fragmented customer data, and no unified purchase history across brands. Each new store added $3,500+ in monthly app costs and operational complexity.
Technical Requirements
The solution needed to:
- Enable rapid cart experimentation without theme redeployments
- Extend subscription platform capabilities through controlled automation
- Support unified checkout across multiple Shopify instances
- Maintain existing integrations and customer data
- Provide operations teams with self-service tools
Tech Stack
| Technology | Purpose |
|---|---|
| Shopify | Core ecommerce platform, checkout, order management |
| Rebuy | Cart and product page personalization engine |
| Ordergroove | Subscription lifecycle management |
| Google Cloud Platform | Cloud Run for microservices, Cloud Scheduler for automation |
| Node.js | Backend logic and API orchestration |
| Liquid | Theme customization and templating |
Image: Technical architecture diagram showing Aroma360's custom Shopify implementation
Implementation
Custom Cart Architecture with Rebuy
The Problem
Shopify's native cart provided limited flexibility for the personalization and testing requirements needed at Aroma360's scale. Each cart modification required theme updates, extending iteration cycles and increasing deployment risk.
The Approach
Rather than treating Rebuy as a standard widget library, we built fully custom cart templates that functioned as a complete rendering layer. This separated presentation logic from business rules, enabling rapid experimentation.
Key Features Implemented:
- Multiple cart layouts — Visual-first, subscription-focused, and offer-driven designs
- Conditional merchandising — Logic based on cart contents, customer location, and purchase history
- In-cart subscription upgrades — Customers could convert one-time purchases to subscriptions during checkout
- Integrated upsells — Product recommendations based on cart compatibility and customer preferences
- A/B test infrastructure — Framework for testing different cart experiences without code deployments
Image: Three custom Rebuy cart layouts
Technical Implementation:
Cart templates lived in Rebuy's custom template system, with decision logic controlled through:
- Shopify customer metafields for segmentation
- Cart attribute data for state management
- API calls to GCP services for complex business rules
- Event tracking to analytics for performance measurement
Impact:
- A/B testing velocity: 4 weeks → 48 hours per test cycle
- Cart conversion rate: +23% through personalized upsells
- Average order value: +32% ($142 → $187)
- Development efficiency: Marketing team could test offers independently
Extending Subscription Capabilities
The Problem
Ordergroove provided excellent baseline subscription functionality, but operations needed bulk actions, conditional automation, and edge case handling not available in the standard platform.
The Approach
We built a microservices layer using GCP Cloud Run that listened to events from both Shopify and Ordergroove, executing custom workflows through secure API integrations.
Architecture:
Shopify Events ─────┐
├──> GCP Cloud Functions ──> Custom Logic ──> Ordergroove API
Ordergroove Events ─┘ └──> Shopify API
Image: Subscription automation workflow
Key Components:
| Component | Function |
|---|---|
| Event listeners | Captured subscription lifecycle events from Ordergroove |
| Business logic layer | Executed conditional workflows (pause, skip, modify) |
| Shopify app UI | Gave operations team interface for bulk actions |
| Audit logging | Tracked all subscription mutations for compliance |
Specific Workflows Automated:
- Bulk pause/resume for weather-affected regions
- Automatic subscription adjustments for inventory constraints
- Custom gift subscription handling (different billing/shipping)
- Renewal reminder sequences based on customer segments
- Failed payment recovery with progressive retry logic
Technical Safeguards:
- No direct database access to Ordergroove
- All mutations through official APIs with rollback capability
- Rate limiting to prevent cascade failures
- Full audit trail of automated actions
- Manual override available for operations team
Impact:
- Operational hours: 40 hours/week → 5 hours/week for subscription management
- Edge case resolution: Same-day → Previously took 2-3 days with engineering involvement
- Automation reliability: 99.8% success rate for bulk actions
- Customer satisfaction: Faster response to subscription modification requests
Multi-Store Shared Checkout
The Problem
Launching new brands (Hotel Collection) required separate Shopify stores, creating customer experience fragmentation and operational complexity. Customers couldn't maintain a unified cart or view complete purchase history across brands.
The Approach
We implemented a shared cart state system that allowed customers to build carts across multiple storefronts while maintaining a unified checkout experience.
Architecture:
Aroma360 Store ───┐
├──> Centralized Cart State ──> Unified Checkout
Hotel Collection ─┘
Image: Multi-Store Checkout Flow
Key Features:
- Cross-store cart persistence — Cart maintained across brand storefronts
- Product compatibility validation — Prevented incompatible product combinations
- Unified customer accounts — Single login across all brand properties
- Consolidated order history — Complete purchase visibility regardless of store
- Brand isolation — New stores could be tested without affecting core site
Technical Implementation:
- Cart state stored in customer metafields
- Session management through secure tokens
- Product catalog sync to validate cross-store compatibility
- Checkout redirect logic to primary store
- Post-purchase order routing to appropriate fulfillment systems
Impact:
- Brand launch timeline: 18 months → 6 months (for Hotel Collection)
- App duplication costs: Saved $3,500/month per additional store
- Customer experience: Unified cart reduced friction for multi-brand purchases
- Engineering risk: Isolated new brand experiments from core revenue
Technical Learnings
What Worked Well
1. Extend, Don't Replace
Treating Rebuy and Ordergroove as platforms to extend (rather than replace) preserved vendor support while adding custom capabilities. This reduced development time and maintained upgrade paths.
2. Clear Separation of Concerns
Keeping UI, business logic, and operational workflows separate allowed teams to move independently. Marketing could test cart offers while engineering worked on subscription automation without conflicts.
3. Early Investment in Internal Tools
Building a Shopify app for operations teams (week 2 of the project) enabled self-service subscription management. This prevented engineering from becoming a bottleneck as subscription volume grew.
What We'd Do Differently
1. Event Schema Standardization
We should have standardized event data structures earlier. Inconsistent schemas between Shopify webhooks, Ordergroove events, and our custom systems created unnecessary mapping complexity downstream.
2. Automated Testing for Experiments
Cart and offer experiments would have benefited from automated visual regression testing. We relied too heavily on manual QA, which slowed iteration as test volume increased.
3. Documentation from Day One
We documented workflows after they were built, leading to knowledge gaps during team transitions. Starting with documentation templates would have prevented tribal knowledge accumulation.
Performance Considerations
Critical Decisions:
- Minimized synchronous API calls in cart/checkout flows to maintain sub-second response times
- Cached business logic results to avoid repeated computation during high-traffic periods
- Strict script loading policies prevented any third-party code from blocking checkout
- Progressive enhancement ensured core functionality worked even when personalization services were unavailable
Metrics:
- Cart page load: <1.2 seconds (p95)
- Checkout initiation: <800ms (p95)
- API response times: <200ms (p95)
- Zero cart-related checkout failures during Black Friday/Cyber Monday
Developer Recommendations
For Teams Building Similar Systems
1. Keep Complex Logic Out of Themes
Avoid pushing business rules into Liquid templates. Move logic to JavaScript services or backend APIs where it can be tested, versioned, and maintained properly.
Don't: Complex conditional logic in Liquid
Do: Business rules in services, Liquid for presentation only
2. Treat the Cart as a Product
The cart isn't just a UI component—it's a conversion surface that needs the same attention as any product feature. Build it with A/B testing, analytics, and iteration in mind from the start.
3. Build Internal Tools Early
Don't wait until operations teams are overwhelmed. Internal tooling should be part of the initial architecture, not an afterthought.
4. Invest in Observability
Logging, monitoring, and alerting aren't optional at scale. Build observability into the architecture from day one:
- Event logging for all cart interactions
- Performance monitoring for API calls
- Error tracking with context
- Business metrics dashboards for stakeholders
5. Version Your Experiments
Track cart layouts, offers, and subscription workflows like code versions. This enables rollback, comparative analysis, and prevents "experiment debt" accumulation.
Results Summary
Quantified Outcomes
| Metric | Before | After | Improvement |
|---|---|---|---|
| Average Order Value | $142 | $187 | +32% |
| Cart Abandonment | 72% | 61% | -11 pp |
| Upsell Acceptance | 8% | 23% | +188% |
| A/B Test Cycle | 4 weeks | 48 hours | 12x faster |
| Subscription Ops Hours | 40/week | 5/week | -88% |
| Brand Launch Timeline | 18 months | 6 months | -67% |
Strategic Value
Operational Efficiency: Reduced manual work from 40 hours to 5 hours weekly, freeing the team to focus on growth initiatives rather than maintenance.
Experimentation Velocity: 12x faster testing cycles enabled data-driven optimization at a pace previously impossible with native platform constraints.
Multi-Brand Scalability: Unified checkout architecture reduced the cost and complexity of launching new brands, enabling faster market testing.
Platform Flexibility: Extended Shopify's capabilities without migration risk, preserving existing infrastructure while unlocking enterprise-grade features.
Conclusion
Scaling ecommerce operations beyond platform defaults requires treating custom development as systems architecture, not just feature implementation. For Aroma360, investing in:
- Cart architecture that enabled rapid experimentation
- Subscription workflows that evolved with business needs
- Multi-store systems that reduced launch friction
...created measurable operational and revenue impact while maintaining the flexibility to iterate as the business grew.
The biggest wins came from extending existing platforms (Rebuy, Ordergroove) rather than replacing them, separating concerns to enable team independence, and building for operations teams early rather than treating internal tools as an afterthought.
View the Full Case Study
This technical deep-dive covered implementation details and architecture decisions. For the complete business story, visual showcase, and client perspective, explore the full Aroma360 case study.
Let's Discuss Your Project
Working on similar scaling challenges? Whether you're evaluating custom development, planning multi-brand architecture, or extending subscription platforms, we'd be happy to discuss your technical requirements.
Get in touch: Schedule a consultation
