Considered, elevated, and built to last. The platform should feel the same.
Corda has a clear brand vision and a considered product. This proposal is about everything customers never see: the commerce platform and the connected systems that make an elevated D2C furniture brand run quietly, reliably, and at scale.
Considered, elevated, and built to last. The platform should feel the same.
Most developers will quote you a Shopify theme. Your brief asks for something materially harder: a connected operation. Three order types, In-Stock, Made-to-Order and Backorder, each flowing cleanly through inventory, fulfilment, freight, support, reviews and accounting, with the right message reaching the customer at every step.
That is the real project. The storefront is the visible tenth of it. The other nine tenths is the integration architecture you've mapped out, and getting that architecture right is the difference between a brand that scales calmly and one that drowns in manual workarounds six weeks after launch.
This proposal is structured around that reality. It is honest about what is achievable by Boxing Day, deliberate about what should wait, and clear about where the genuine technical risk sits, so you can make a confident decision about who you partner with.
Every system you've listed is sound. Not all of it needs to exist on day one. We sequence the build so you launch on time with what matters, and add operational automation as order volume justifies the cost and complexity.
Documented integration logic, a system map, and credentials handed to you. No lock-in, no black boxes. You asked to own your technology in the same detail you document your business. That is exactly how we work.
The inventory and order-routing layer is the riskiest piece of this build. We prove it in a sandbox before a single page is polished, so the foundation is solid before anything is built on top of it.
Considered, elevated, and built to last. The platform beneath it should feel exactly the same.
Your brief maps eight system-to-system flows. Below is our read on each: what it does, and which phase it belongs in. The colour-coding is deliberate. The amber flows are launch-critical. The muted flows are operational leverage we recommend building once you have live orders moving through the system.
Your brief asks for a system map showing how every platform connects and what triggers what. Rather than describe one, here it is, working. Hover any system to trace its connections. This is a live preview of the documentation you'll own at handover.
Tap a system on mobile.
The heart of your brief is that In-Stock, Made-to-Order, and Backorder cannot be treated the same. Each needs its own path through inventory, production, freight, and customer messaging. Choose an order type to watch how it routes through the connected systems.
Your range is considered, modular, and made to order. The platform has to understand that from the first pixel: product pages that hold many variants without feeling cluttered, lead times shown honestly, and a structure ready for the configurator when it comes. We design the build around the product, not the other way around.
Every build of this kind carries real risk, and most of it sits in the same few places. We'd rather name them now than discover them together in November. Here are the three most likely to bite on this project, and exactly how we handle each.
Once Shopify, Cin7 and freight are all talking to each other, the edge cases live in the handoffs: an order that syncs late, a status that does not write back, a tag that does not carry. Left unmanaged, that is how an order quietly reaches the warehouse wrong.
We use Shopify Flow, Shopify's own automation layer, as the control point. It lets us catch the unexpected coming back from Cin7 and route orders deliberately rather than hoping every system behaves. We map the exact behaviour you want during discovery, then build and prove the routing in a sandbox against real order scenarios before the storefront is touched. It is the first thing we build, not the last.
Shopify caps a product at 100 variants. Made-to-order furniture across size, fabric, configuration and finish can quietly exceed that, and the excess variants simply fail to appear, a problem that surfaces late and badly if it isn't planned for.
We model the catalogue around this constraint from day one, splitting high-variant products by a primary attribute and driving the rest through metafields and metaobjects rather than raw variants. Your design studio's PDP design and our product architecture are aligned before build, so the structure is decided deliberately, not discovered mid-launch.
Furniture freight is not parcel freight. Dimensional weight, two-person delivery, depot restrictions and bulky-item surcharges all apply, and a checkout that quotes parcel rates will quietly erode margin on every order.
We configure Shippit specifically for bulky freight, with carrier rules and vehicle types matched to your product dimensions, validated against your actual SKU range before launch. Freight logic is tested with real dimensions and destinations, not assumed, so the rates customers see reflect what delivery actually costs.
Your proposed stack is well-researched. We agree with most of it, and have two considered recommendations that save meaningful money at launch without compromising the architecture. You asked for guidance, not just agreement, so here it is.
This is the case for building it properly, once. The Phase 1 investment is not the cost of a website. It is the cost of never running this operation by hand. Every order, from the first, flowing to the right place with the right message, without a person holding it together. Measured against a year of manual workarounds, it pays for itself well before Boxing Day is over.
Developer-ready, with named frames and design tokens, from your studio. We'll work alongside them through UX/UI so the handover is clean.
Real production and freight timeframes per category, so the made-to-order messaging and PO logic reflect how you actually operate.
Admin access to the platforms as we connect them. You'll own every credential and API key, documented and handed back at the end.
A single point of contact on your side who can make calls quickly. Momentum is what protects a Boxing Day launch.
You asked for a single named developer and solutions architect on your account. With us, that's not a concession. It's the model. No hand-off to a junior after the pitch, no account managers between you and the work.
Shopify, Cin7, Klaviyo, Shippit, working together. We know where the Cin7 connector strains, how to model high-variant products around Shopify's limits, and which flows earn the most. You're not paying us to learn on your project.
The brief is bigger than a single budget line, and we've said so plainly rather than quietly under-delivering. You'll always know what's launch-critical, what can wait, and where the genuine risk sits.
Same city, same timezone, no offshore lag. When something needs a decision or a fix, you reach the person responsible, and it moves in hours.
A proper discovery is where a build like this is de-risked: turning your SoP documentation into a technical specification, pressure-testing the integration architecture, and confirming exactly what each system needs to do. We run this as a paid engagement for most clients. We'd like to include it at no cost here, because we want this one and we'd rather earn it by showing you the thinking than by talking about it.
Every figure in this proposal is indicative, scoped from what we have today and the Boxing Day timeline. Once discovery is done and your Figma is in hand, we'll convert it into a fixed Statement of Work with confirmed pricing.
The shape is here. The pricing is indicative, based on the brief in front of us and the urgency of a Boxing Day launch. The next step is the discovery above: a short working session that turns all of this into a precise Statement of Work, with the numbers confirmed.