Menu

SOLUTION · COMPOSABLE COMMERCE

Composable commerce, built for businesses that have outgrown the monolith.

When you sell across multiple channels, multiple brands, or multiple business models, a single platform almost never covers all of it. Composable commerce splits the stack into independent layers connected by event-driven middleware. Each layer chosen on merit.
Composable Commerce Banner

Best-of-breed front end, commerce engine, OMS, ERP, and PIM connected by Nexus. No single point of failure, no single vendor holding your roadmap.

What composable commerce actually means

Traditional commerce platforms are monoliths. Shopify, Magento, BigCommerce, and Salesforce Commerce Cloud each bundle the storefront, the cart, the checkout, the catalog, the customer database, the order management, the discount engine, and the basic content management into a single platform you configure. For most retailers, this is exactly the right shape.

For 80% of retailers, the monolith is the right answer. For the other 20%, the monolith is the source of most of their pain. The features you need are blocked behind workarounds. The features you do not need are unavoidable. The platform’s roadmap is not your roadmap. You are paying the vendor to slow you down.

Composable commerce splits the stack into independent layers. Each layer is chosen on merit. Each layer talks to the others through APIs and events. If the front end framework you want is React-based, you use it. If your commerce engine of choice is Shopify Plus but you need a different OMS, you compose them. If your business model needs a custom checkout that no SaaS supports, you build it. The pieces are independent; the system is whole.

The trade-off is real. Composable commerce is more expensive to build than a Shopify theme. It requires architectural decisions you do not need to make on a monolith. It requires a team that can hold the whole picture, not just one platform. But for businesses with complexity that monoliths cannot accommodate, composable is the difference between operating cleanly and fighting your platform every day.

The honest moment most agencies skip: most retailers should not go composable. If Shopify Plus or Adobe Commerce covers 95% of what you need, the cost of composing your own stack vastly exceeds the cost of living with that 5%. We will tell you that directly. About one in three composable commerce discoveries we run ends with our recommendation to stay on Shopify Plus and just upgrade specific parts of the stack. The discovery cost is the audit deliverable. The MACH Alliance publishes good material on when composable is and isn’t justified; we treat that bar as the right one.

If you have run into the ceiling on a monolithic platform, call 0431 000 062. We will talk you through whether composable is the right move for your business.

Symptoms to look for

Composable commerce becomes the right answer when one or more of the following are true.

  • You operate multiple brands or multiple regions. Each needs its own storefront, but the catalog, the inventory, and the customer base should be shared. Standing up four Shopify stores duplicates the back office four times.
  • You sell B2B and B2C from the same business. The two models need very different checkouts, very different pricing rules, and often very different fulfilment workflows. Bolting one onto the other inside a single platform is where most B2B-on-Shopify projects fail.
  • You hit Shopify Plus or Magento limits. Catalog size, custom checkout rules, complex pricing, complex tax, or specific compliance requirements that the platform cannot do without ugly workarounds. The workarounds have started costing more than the licence.
  • You need a content-led front end. Editorial control, complex content models, and design flexibility that platform themes cannot deliver. The marketing team has been asking for the same three things for two years and the platform cannot do them.
  • Your back-end systems are non-negotiable. You already run a particular ERP, OMS, or PIM that the business depends on, and the commerce platform needs to fit around them. The commerce side is not the centre of gravity; the operations side is.
  • You acquire businesses or launch new brands frequently. Each new brand or business unit needs a storefront fast, but should plug into the same back office. Composable lets you ship a new brand in weeks, not months, because the infrastructure is already there.
  • Front-end performance is a strategic priority. Core Web Vitals, mobile load times, conversion rates at scale. Platform themes have ceilings; composable storefronts on modern frameworks routinely outperform monolithic platforms by significant margins. If a tenth of a second of page load is worth seven figures to you, the architecture matters.

DIAGNOSTIC

If three or more describe your situation, composable is probably the cleaner answer. The question shifts from whether to compose, to how to compose.

The architecture we deploy

Composable Commerce Content

Composable commerce works because every layer is decoupled and every layer communicates through stable contracts. Nexus is the middleware that makes that work.

The front end layer

Typically Next.js, Nuxt, or a similar modern framework. Server-side rendered for SEO, hydrated for interactivity, deployable to Vercel, Cloudflare Pages, or your own infrastructure. The front end is independent of the commerce engine, which means you can redesign without re-platforming. Your front end and your commerce backend evolve on separate roadmaps.

The commerce engine

Shopify Plus, Adobe Commerce, BigCommerce, or a custom engine on Symfony, depending on requirements. The commerce engine handles catalog, cart, checkout, pricing, and order capture. Beyond order capture, control passes to the OMS. We have built composable architectures with each of the major commerce engines as the core; the choice is driven by your specific operational requirements, not by any vendor preference of ours.

The OMS, ERP, and PIM

Order management, inventory, fulfilment, accounting, and product information each live in the system best suited to the job. Dear Systems, Cin7, NetSuite, Brightpearl, Microsoft Dynamics, or custom-built. The commerce engine does not try to do these jobs. Each layer is in the system that is genuinely good at it, not the system that pretends to be good at it.

Nexus, the event bus

Every order, every inventory change, every customer update, every refund, fires an event. Nexus routes the event to the systems that need it. Idempotent handlers prevent double-processing. Every event is logged for audit. Replay is supported when downstream systems have outages. When NetSuite has a scheduled maintenance window at 11pm on a Sunday, your orders queue in Nexus and drain when NetSuite returns. The customer-facing experience never knew it happened.

The PIM layer

Product information typically lives in a dedicated PIM (Akeneo, Plytix, or custom) when the catalog has more attributes than a commerce platform was designed for. Product data flows from the PIM to the commerce engine, the storefront, the marketplaces, and the data feeds. A single source of truth for product means one team owns the data, and every downstream channel gets it correctly.

The audit trail

Every event, every transformation, every retry is logged. When the auditor asks what happened on 14 March at 3:47pm, you open a dashboard and show them. When the finance team asks why a specific refund posted to the wrong account, you answer in two minutes. The composable stack has more components than a monolith, but the audit story is genuinely better because every system-to-system interaction is captured at the middleware layer.

How we build it

Composable commerce builds run in four named phases. Each phase is fixed scope and fixed price. You can pause between any two phases without losing progress.

  1. DISCOVERY AND ARCHITECTURE

    3 to 4 weeks. Map current state, document business model, select stack components, write the integration contracts. Fixed scope and quote at the end.

  2. FOUNDATION

    4 to 6 weeks. Stand up Nexus, integrate commerce engine and core back-office systems, prove the event flow end-to-end against production-shaped data.

  3. FRONT END AND CUSTOMER EXPERIENCE

    6 to 12 weeks. Build the storefront, the checkout, the customer portal, and any custom front-end experiences. Performance-optimised from day one.

  4. LAUNCH AND CUTOVER

    3 to 6 weeks. Migrate from the existing platform, soft launch, hard launch, monitor closely for the first weeks.

Total: 16 to 28 weeks for a single-brand composable build. Multi-brand and multi-region builds extend timelines, but the foundation work is reusable. The second brand on the same composable platform ships in roughly half the time of the first.

Three engagement shapes

We structure composable commerce engagements one of three ways. All three start with discovery and architecture.

  • Single brand. From $80,000. One storefront, one commerce engine, one OMS, connected by Nexus. 16 to 20 weeks. Best for businesses making their first move off a monolith.
  • Multi-brand platform. From $150,000. Shared infrastructure, multiple storefronts, shared catalog and customer data. 24 to 32 weeks. Best for groups operating multiple brands or planning to acquire more.
  • Run With Us retainer. From $6,500 per month. Post-launch monitoring, continuous additions, security patching, quarterly architecture review. Best for composable stacks where the roadmap continues to evolve.

Call 0431 000 062 to talk through which fits.

Composable commerce we have built

Three composable commerce builds. Two named clients, one confidential at client request. Reference calls available.

WHMA group, multi-site beauty retail

  • Problem: Beauty group with 180+ locations, Zenoti as the booking and POS engine, Shopify Plus for retail, and a need for inventory parity across both. Shopify alone could not handle the booking logic. Zenoti alone could not handle the storefront. Neither vendor could solve the other half of the problem.
  • Built: Composable architecture with Shopify Plus as commerce engine, Zenoti as booking/POS, Nexus as middleware. Event-driven inventory sync. Single customer record across both systems. Built over 22 weeks.
  • Result: Inventory parity across three systems achieved. Online and in-store stock now reflect reality. Booking and retail data join in the same reporting layer for the first time. Marketing campaigns can now target customers based on combined service and retail history.
  • Stack: Shopify Plus, Zenoti API, Nexus middleware, PostgreSQL, AWS Sydney, event sourcing architecture.

Wesfarmers, marketplace payments

  • Problem: Multi-vendor commerce model requiring split payments to multiple parties on every transaction. Standard commerce platforms could not do this cleanly. Vendor onboarding, payout calculation, and reconciliation each had their own bespoke processes.
  • Built: Composable architecture with Stripe Connect handling split payments, custom front end, Nexus orchestrating the order and payout flow. Each order triggers automatic split calculation and payout. Built over 18 weeks.
  • Result: Vendor payouts automated. Reconciliation moved from weekly manual work to daily automated reporting. Platform now ready for vendor expansion without architectural changes.
  • Stack: Custom front end (Next.js), Shopify Plus, Stripe Connect, Nexus middleware, PostgreSQL, AWS Sydney.

A multi-brand fashion group, name confidential

  • Problem: Fashion group operating four distinct brands across two regions. Each brand had its own Shopify store, its own product catalog management, its own customer service team. Group-level reporting was impossible. Onboarding a new brand (which the business did roughly once a year) took six months and a fresh Shopify build each time.
  • Built: Composable platform with shared PIM (Akeneo), shared inventory layer, shared customer database, brand-specific Shopify storefronts. Each brand keeps its own storefront identity; the back office is unified. Built over 26 weeks.
  • Result: Group-level reporting now available in real time. Time to launch a new brand reduced from 6 months to roughly 8 weeks. Customer service team consolidated across all four brands with a unified customer view. The fifth brand launched on the existing platform with no infrastructure work.
  • Stack: Next.js storefronts, Shopify Plus (multi-store), Akeneo PIM, Cin7 Core inventory, Xero accounting, Nexus middleware, PostgreSQL, AWS Sydney.

Who you will work with

Composable commerce builds are multi-quarter commitments involving operations, finance, marketing, and engineering. You should know the people doing the work, and they should know you. The two engineers below scope, build, and ship the work. The senior engineer who runs your architecture session is the same engineer who writes the Nexus code. No discovery handover. No offshore subcontract.

  • Image 3

    Nicolas Wendell

    MANAGING DIRECTOR

    Nicolas has been building custom software since leaving school, bringing a lifelong passion for development to every project. Before founding Paladine Systems, he ran his own video game studio and earned multiple accolades in network engineering. Known as a driving force in the custom software world, Nicolas combines deep technical expertise with visionary leadership – guiding Paladine in delivering innovative, enterprise-grade solutions.

  • Image 4 (1)

    Mark Morcom

    SENIOR SYSTEMS ENGINEER

    Mark is a young prodigy in software development, bringing 5 years of experience to Paladine. Equally at home on the front end and back end, he crafts clean, scalable solutions that power complex applications. Mark’s sharp problem-solving skills and passion for innovation make him a driving force behind Paladine’s most advanced projects.

Composable commerce FAQs

  • Is composable commerce just headless commerce?

    Headless is one piece. A headless storefront is a separated front end on top of a monolithic commerce engine. Composable goes further, separating the OMS, the ERP, the PIM, and other layers as well. Headless solves the front end problem. Composable solves the whole stack problem. Headless is a subset of composable, not a synonym.

  • When is composable the wrong answer?

    When a monolith covers 95% of what you need. The complexity overhead of composable architecture is real, and if Shopify Plus or Adobe Commerce can do the job out of the box, that is a better commercial decision. About one in three composable discoveries we run ends with our recommendation to stay on the monolith.

  • Do we lose the speed advantages of a monolithic platform?

    Some, yes. Configuring a Shopify theme is faster than building a composable storefront. The trade-off is flexibility and ceiling height. Once you are past the build phase, day-to-day operations on a composable stack are not slower; they are just different. The build is longer; the runway is meaningfully longer too.

  • Can you compose with our existing ERP?

    Almost certainly. We integrate with NetSuite, Microsoft Dynamics, Dear, Cin7, Xero, MYOB, and custom ERPs. The point of composable is that each layer is independent, so your existing ERP becomes the system of record for accounting and inventory. You do not need to replace the systems that are working.

  • How does this compare to Shopify Plus on its own?

    Shopify Plus is a strong commerce engine. For many businesses it is also a complete answer. Composable becomes the right answer when you need pieces Shopify cannot do, or when you outgrow its ceiling. Even within a composable stack, Shopify Plus is often the commerce engine; what changes is what surrounds it.

  • Do you build the front end as well, or just the middleware?

    Both. We build the entire stack, or we integrate into a front end your existing partner has built. Either model works. Click Click Media, our parent group, handles front-end and design work where you want a single team across both sides; otherwise we are happy to work alongside your existing front-end partner.

  • What happens if one layer needs to be replaced later?

    That is the point of composable. If the OMS layer no longer fits, you swap the OMS without touching the storefront, the commerce engine, or the ERP. Nexus’s event contracts are designed to make that replacement straightforward. The cost of swapping a layer in a composable stack is a fraction of the cost of re-platforming a monolith.

  • How do we get started?

    Call 0431 000 062 or book a discovery call through the form below. The first conversation is free and is run by an engineer. We will tell you whether composable is the right next step. Sometimes the answer is to stay on Shopify Plus and upgrade specific pieces, and we will say so.

GET STARTED

You have outgrown the monolith, or you have been told Shopify Plus is your only option. Get a composable stack that fits the business.