Contents · 7 sections
- 01Building is not just frontend development.
- 02Architecture decisions compound over time.
- 03Most build projects fail through misalignment.
- 04A build is an operational project, not a website.
- 05Performance and stability are features.
- 06Selected build case studies.
- 07Stable platforms are designed that way.
- 08Common questions.
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, kickoff to go-live ──────────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
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.
08 · Questions we get asked
Common questions.
What does a build engagement with iWeb actually cover?
A build engagement covers the commerce platform, the integrations that make it tradeable (ERP, PIM, OMS, payments, tax, search) and the release pipeline it ships through. The storefront is one deliverable among several, not the project.
Which platforms do you build on?
Adobe Commerce, Magento Open Source, Shopify Plus, commercetools, BigCommerce, Centra and Hyva Commerce for the storefront; Akeneo PIM, Salsify and Informatica for product data. Selection is driven by the integration map and operating model, not preference.
How long does a new build take?
Most B2B and operational builds iWeb runs land between five and nine months from kick-off to trading. Integration scope and data readiness set the timeline; the storefront is rarely the critical path.
How do you avoid the usual build overrun?
Scope the integration boundary, data model and release pipeline before committing to a date. Named senior engineers stay on the account from scope through to launch, and change requests are priced against the same plan rather than a moving target.
What happens after launch?
The same team runs a stabilisation window, then hands over to managed support with a written runbook covering the storefront, middleware and ERP integration. Nothing is thrown over a wall.