--- title: "The commerce platform behind a manufacturer's D2C leap" url: https://www.axelerant.com/blog/commerce-platform-manufacturer-d2c-leap published: 2026-07-22T10:00:00Z author: "Bassam Ismail, Director of Digital Engineering" source: Axelerant Thinking --- # The commerce platform behind a manufacturer's D2C leap > How a UK kitchen manufacturer went from offline, bulk B2B orders to a full online D2C buying journey on a composable commerce platform. A kitchen manufacturer that supplies housebuilders operates at a scale most retailers never see. Five hundred kitchens into a tower block. Trucks full of identical units. Systems tuned for contracts, not customers. Our client, a UK kitchen manufacturer, had spent decades getting very good at exactly that. Then they decided to sell one kitchen at a time, direct to consumers, entirely online. That sentence hides the real problem. Their website was a brochure. Orders ran on offline, manual processes from placement through delivery. Every back-office system assumed bulk. Even packaging a single kitchen for one household worked differently from loading a contract shipment. The competition they wanted to beat had been born D2C and self-serve. This was a business transformation wearing an e-commerce project as a jacket. ### What we ran into Discovery started with the vision still forming. The client and their design agency partner were shaping requirements as we went, and our early proofs of concept kept changing as everyone converged on what the experience should be. We could have fought that. We chose not to, because the alternative was locking scope against a business model nobody had operated yet. Then the calendar moved. Implementation was planned for October 2025 and started in January 2026. Once it did start, the dependencies arrived in the wrong order. Product data in the client's PIM was still being finalized while we were building against it. UI and UX deliverables slipped by nearly a sprint. The original payment implementation had to be replaced entirely mid-project. And the product metadata for the 3D kitchen planner, the feature the whole journey hinges on, was locked two weeks before go-live. None of this is unusual for a company mid-transformation. What matters is whether the architecture and the delivery approach can absorb it. ### The architecture decision We went composable: a Next.js frontend talking over GraphQL to two decoupled backends. Magento 2 runs commerce, meaning products, pricing, orders, customers, and discounts. Strapi runs content, meaning navigation, brand storytelling, inspiration pages, and everything editors touch daily. Why two backends instead of doing everything in Magento? Two reasons we would defend in any review. First, the design demanded component-level flexibility Magento's frontend could not deliver without heavy compromise. Second, Magento's admin is a hostile place for a non-technical content editor, and this client's marketing team needed to run content without filing tickets. A lean CMS beside a commerce engine solved both. [We wrote up that decision in detail separately](/blog/strapi-magento-composable-commerce). The honest cost: in a headless architecture, seemingly simple changes can require work across multiple systems. A change that touches product data, presentation, and content can touch Magento, Next.js, and Strapi in one ticket. We knew that going in and priced it into how we planned sprints. Anyone selling you headless without mentioning this is selling. ### The planner is the product The heart of the platform is a third-party 3D kitchen planner, embedded in the frontend as an iframe with substantial custom orchestration code around its APIs. The commerce catalog is mirrored inside the planner, so a customer designs a real kitchen from real, purchasable products. When they finish, the design converts into a bill of materials that syncs into the Magento basket, merging with whatever samples or accessories are already there. The plan ID stays locked to that basket through checkout and passes to the manufacturer on the order, so fulfillment can trace every order back to the exact design. The full engineering picture lives in [the integration that makes design-to-order commerce actually work](/blog/magento-3d-planner-integration). Mid-project, we discovered the existing planner integration was built on deeply hardcoded behavior that would not survive contact with the remaining requirements. One of our frontend engineers redesigned it and shipped the rework, estimated at a full sprint, in two days. AI-assisted development made that pace possible, and [we wrote about that workflow separately](/blog/ai-assisted-development-commerce-launch), but the decision to rebuild rather than patch was human judgment about where the platform's risk actually lived. ### Shipping while the ground moved Three delivery choices kept the launch date credible. We treated MVP data pragmatically. Rather than block launch on automated PIM integration, product data flows into Magento via structured CSV import, with automation scoped for the next phase. That is a compromise, documented as one, and the right one. [We unpacked the framework behind those data decisions here](/blog/ecommerce-launch-with-incomplete-product-data). We ran design two sprints ahead of development across a twelve-sprint implementation, with demos every other week and a 48-hour design feedback loop between us, the design agency, and the client. When design slipped, the buffer absorbed most of it. And we managed change through priced, contingency-funded change requests instead of silent scope growth. Planner entry and exit behavior, CMS-controlled sort ordering, checkout terms handling: each one estimated, approved, and tracked. The final week still tested everyone. Planner integration issues, production readiness, launch blockers, daily uncertainty. The site went live in July 2026, and the first live payment went through on launch day. A business that could not sell online now does, end to end: design in 3D, price, pay, schedule delivery. ### What you can take from this If you are taking an established B2B operation direct to consumer, the website is the last problem you will solve, not the first. Budget your architecture for dependencies that will not hold still: decouple what changes at different speeds, make your data compromises explicit and reversible, and treat your core differentiating integration, whatever your equivalent of the 3D planner is, as the thing you prototype earliest and rebuild without sentiment when it is wrong. The businesses that get D2C right are not the ones with perfect plans. They are the ones whose platforms absorb imperfect ones. The bigger market pattern behind this shift, and what it means for other trade-channel businesses, is in our companion piece: [the kitchen industry just told manufacturers where the market is going](/blog/kitchen-manufacturers-d2c-market-signals). If you are navigating a shift like this, we would be glad to think through it with you. --- Read on the web: https://www.axelerant.com/blog/commerce-platform-manufacturer-d2c-leap