A specialty retailer with 45 locations and a growing DTC eCommerce presence invested in a composable commerce architecture in early 2023. Within 18 months, they faced three significant business pivots: launching a wholesale B2B channel, expanding into marketplace selling, and implementing same-day local delivery — none of which were in the original scope. Their platform absorbed all three without architectural rework. Here’s how.
The Initial Architecture Decision
The retailer had been running a monolithic Magento 1 instance that served their basic eCommerce needs but couldn’t support the omnichannel ambitions their board was pushing. Every new capability request — BOPIS, inventory visibility, personalization — required core modifications that risked destabilizing checkout.
The team evaluated three paths: upgrade to Magento 2 monolithic, move to Shopify Plus, or invest in a composable architecture with Magento 2 as the commerce engine behind a headless frontend with discrete services for inventory, OMS, and content.
They chose composable — and critically, they chose an implementation partner with the Hyvä and Magento expertise to build it properly rather than just architecturally. Bemeir’s team led the architecture and implementation, designing each service boundary with explicit extension points for capabilities that didn’t exist yet in the roadmap.
The guiding principle was simple: every service owns its domain data completely, communicates exclusively through well-defined APIs, and can be replaced independently without affecting other services.
Pivot 1 – Wholesale B2B Channel (Month 6)
Six months after the DTC platform launched, the retailer’s board identified a wholesale opportunity worth $15M annually. B2B commerce requires fundamentally different capabilities than DTC: custom pricing per account, bulk ordering, quote workflows, net payment terms, and purchase order integration with buyer ERP systems.
On a monolithic platform, adding B2B typically requires a separate installation or a significant extension that touches core checkout logic. On their composable architecture, it required three additions: a B2B pricing service that overrode standard pricing based on authenticated account context, a quote workflow service that managed the request-quote-approve lifecycle, and a payment terms service that integrated with their accounts receivable system.
| Capability | DTC Implementation | B2B Addition | Shared Layer |
|---|---|---|---|
| Product Catalog | Hyvä frontend | Bulk order UI | Magento catalog service |
| Pricing | Standard tier pricing | Account-specific rules | Pricing service API |
| Checkout | Card payment only | Quote + Net terms + PO | OMS handles both |
| Fulfillment | Ship-to-consumer | Pallet/freight + ship-to-consumer | Inventory service (unified) |
| Account Management | Consumer profiles | Company hierarchy + buyer roles | Authentication service |
The B2B channel launched 10 weeks after the board decision. On their previous monolithic architecture, their Magento agency had estimated 6-8 months for equivalent B2B capability. The composable approach delivered it in less than a quarter.
Key architectural decision that enabled speed: The original OMS implementation was designed to handle “order types” generically rather than assuming all orders were DTC. Adding B2B order types (with different fulfillment rules, payment workflows, and communication templates) was configuration rather than code change.
Pivot 2 – Marketplace Expansion (Month 11)
By month 11, the competitive landscape shifted. Amazon and specialty marketplaces were capturing market share in the retailer’s category. The board mandated marketplace presence on Amazon, their vertical’s dominant marketplace, and their own direct marketplace where third-party sellers could list alongside first-party inventory.
Marketplace operations introduce massive complexity: multi-seller inventory aggregation, seller onboarding, commission structures, seller-fulfilled vs platform-fulfilled orders, dispute resolution, and marketplace-specific pricing strategies.
Because the architecture separated inventory, pricing, and fulfillment as independent services, adding marketplace capabilities meant extending each service rather than rebuilding the platform. The inventory service gained multi-seller inventory pools. The pricing service gained marketplace commission calculations. The OMS gained seller-fulfillment routing logic.
The third-party marketplace launched 8 weeks after the decision. External marketplace integrations (Amazon, specialty vertical) took an additional 4 weeks for API integration and listing synchronization.
Key architectural decision that enabled speed: The product catalog service was already designed with a content/commerce separation — product data (attributes, images, descriptions) lived separately from commerce data (pricing, inventory, fulfillment rules). This meant marketplace listing data could be generated from the existing content layer without maintaining separate product information for each channel.
Pivot 3 – Same-Day Local Delivery (Month 15)
The third pivot came from competitive pressure — three local competitors launched same-day delivery, and customer surveys showed it was influencing purchase decisions. The retailer needed same-day delivery from their 45 store locations within 15 months of their original platform launch.
Same-day delivery requires real-time store inventory accuracy (not eventual consistency), delivery zone calculation, dynamic delivery time estimation based on store workload and courier availability, and integration with last-mile delivery providers.
The composable architecture handled this through a new delivery service that consumed the existing real-time inventory feed, calculated delivery zones based on store coordinates and provider coverage, and exposed delivery time estimates to the frontend through the same API gateway used by all other services.
Bemeir’s experience with multi-location Magento deployments informed the delivery zone logic — particularly the edge cases around stores with limited staff capacity for pick-pack-ship during peak hours, which require dynamic throttling of available delivery slots.
Implementation took 6 weeks from decision to production. The delivery service consumed existing inventory events, added a courier integration layer (initially DoorDash Drive and a local provider), and exposed availability through the checkout service’s existing shipping method interface.
The Architectural Patterns That Enabled Flexibility
Three specific architectural patterns made all three pivots absorbable without rework:
Event-driven communication — Services publish domain events (order placed, inventory changed, price updated) without knowing which other services consume them. When the B2B pricing service published price-change events, the marketplace listing service automatically consumed them to update marketplace prices — even though the marketplace service didn’t exist when the pricing service was built.
API-first design with versioning — Every service exposes versioned APIs that remain backward-compatible. New capabilities are added through new API versions or new endpoints rather than modifying existing contracts. This means adding the B2B frontend didn’t require changing any API the DTC frontend consumed.
Domain-driven service boundaries — Services are bounded by business domains (inventory, pricing, fulfillment, content) rather than technical layers (database, application, presentation). This meant that when a new business capability emerged, it was immediately clear which services needed extension and which were unaffected.
Financial Impact of Architectural Readiness
The retailer’s CFO tracked the total cost of each pivot against comparable projects at other portfolio companies running monolithic platforms:
| Pivot | Composable Cost | Comparable Monolithic Cost | Time Saved |
|---|---|---|---|
| B2B Channel | $180K (10 weeks) | $600K-900K (6-8 months) | 4-6 months |
| Marketplace | $220K (12 weeks) | $1.2M-1.8M (12-18 months) | 9-12 months |
| Same-Day Delivery | $95K (6 weeks) | $350K-500K (4-6 months) | 3-4 months |
The upfront investment in composable architecture was approximately $400K more than a standard Magento 2 monolithic build. The savings across three pivots exceeded $2M. More importantly, the speed advantage — getting to market 4-12 months faster on each initiative — generated revenue that monolithic competitors are still waiting for.
Why This Worked When Most “Future-Ready” Projects Don’t
The difference between this outcome and the graveyard of over-engineered “future-proof” platforms that never ship comes down to pragmatism in architecture decisions:
They didn’t build for hypothetical requirements. Every service in the initial build served a current business need. The “extension points” were simply clean interfaces and event buses — not speculative features or unused abstractions.
They invested in operational simplicity. Each service could be deployed, scaled, and debugged independently. The team could make changes to the pricing service without coordinating with the inventory team or scheduling a platform-wide release.
They chose an implementation partner with actual composable commerce experience — not a team that read about MACH architecture in a Gartner report and decided to try it on a client project. The difference between theoretical composable and production composable is everything, and it only comes from building and operating these systems at scale.
Future-readiness isn’t about predicting the future. It’s about building architecture that makes absorbing surprises a configuration change rather than a multi-month crisis project.
