Skip to main content
Talk to an expert
ServiceBuild · Current delivery model

A commerce build is an operational project.
We deliver it like one.

Most of the work sits behind the interface, in data, integrations and the operational steps a customer never sees. We build platforms the in-house team can maintain, govern and evolve, and we run the project around them so the business is trading on day one.
Contents · 7 sections
  1. 01Building is not just frontend development.
  2. 02Architecture decisions compound over time.
  3. 03Most build projects fail through misalignment.
  4. 04A build is an operational project, not a website.
  5. 05Performance and stability are features.
  6. 06Selected build case studies.
  7. 07Stable platforms are designed that way.
01 · Scope

Building is not just frontend development.

Most of the complexity sits behind the interface. Pricing rules, account permissions, fulfilment routing, search relevance, ERP and PIM flows, B2B contract terms, returns, tax. The page is the easy part.
We scope the operational behaviour first, then design the experience that exposes it. Teams that start with screens and bolt on the systems later spend the back half of the project undoing their early decisions.
A typical build touches eight to twenty-four upstream and downstream systems. Each has an owner, a release cycle and a view of how it should behave. We map them in week one and write the integration plan before the first sprint.
8-24
Systems integrated
Per build, typical
~70%
Effort behind UI
Data, integrations, ops
2-wk
Release cadence
After go-live
90d
Hypercare
Senior team, post-release
02 · Architecture

Architecture decisions compound over time.

Every customisation has a half-life. The bespoke logic that ships in year one is the constraint that blocks change in year three. We write less custom code on purpose, and document the platform-native behaviour we keep.
The judgement is knowing when not to customise. Most of what teams build bespoke is already in the platform, usually better tested. We reach for extension points before new code, and we name the trade-off in writing when we don't.
Maintainability is a commercial decision. A clean architecture is what makes the next three roadmap items cheap to ship. We optimise for the cost of the second release, not the first.
03 · Delivery

Most build projects fail through misalignment.

Builds rarely fail because the code is wrong. They fail because ownership is unclear, priorities shift mid-flight, operational stakeholders aren't in the room, and dependencies aren't named until they're already late.
We staff the project from the brief: a senior delivery lead, the architects who will design the system, and the engineers who will ship it. The team you meet at scoping is the team that delivers. Decisions are recorded, trade-offs are named, and the operational owners sign the work, not the agency.
04 · Operations

A commerce build is an operational project, not a website.

Warehousing, customer service, finance, merchandising and fulfilment all change shape on the day a new platform goes live. The build is the part you can see. The operational project is the part that decides whether the business is trading on Monday.
4-6 wks
Discovery & scope
12-20 wks
Build & integrate
6-8 wks
Operational readiness
2-4 wks
Release & adoption
12 wks
Hypercare
Kickoff────────── typical 9-12 months end-to-end ──────────Hypercare + 90 days
Operational readiness isn't a sprint at the end. Warehouse process, agent scripts, finance reconciliations and merchandising tooling are built alongside the platform, rehearsed before release, and owned by named people on the customer side at go-live.
05 · Stability

Performance and stability are features.

Stable platforms are designed that way. Resilience, observability and release discipline are built in from the first sprint, not bolted on after the first incident. We instrument what we ship, and we know what's slow before customers do.
Performance problems are usually systemic. They sit in cache strategy, query shape, third-party scripts and the wrong abstraction at a hot path. We treat them as architectural work, not as a tuning pass in the week before launch.
06 · Proof
07 · Platforms

Stable platforms are designed that way.

We build on platforms we know in production, not the ones easiest to demo. Selection is led by operational fit, the integration map and the cost of the second release, not by preference.
Where AI earns its place, it earns it inside operational workflows: product enrichment, support tooling, decision support, with governance and human oversight. We treat it as engineering, not narrative.
Built and run in production
Adaptive Commerce° (by WithPraxis.ai) · Adobe Commerce (Magento) · Shopify Plus · Salesforce ·
commercetools · BigCommerce · Centra · Hyvä Commerce · Akeneo PIM · Salsify · Informatica ·
Adobe Experience Cloud · Contentful · Algolia · Constructor.io · Mirakl Marketplace
Governance & assurance
ISO 27001, 9001 and 42001 certified. Cyber Essentials Plus. WCAG 2.2 AA embedded in delivery. Adobe Solutions Partner Gold, Specialised in Commerce & AI.
Next step

Build properly. Trade on day one. Cheaper to change in year three.

Send the brief. You'll get a written response from a senior expert, scope, integration map, risks and a delivery plan we'd stand behind, not a pitch deck.
Talk to an expertor read how we scope a build →