How we workDelivery approach across replatform, build, rescue and support
How iWeb delivers ecommerce projects.
Our projects bring together commercial requirements, user experience, platform engineering, integrations, data, testing and launch planning. The work is organised around clear responsibilities, regular decisions and practical evidence of progress. The exact process varies by project, but the main stages remain consistent. 600+ projects delivered since 1995.
Contents · 7 sections
- 01Understanding the business and current position.
- 02Agreeing scope, plan and open decisions.
- 03Team structure and who is involved.
- 04Choosing platform, extension or custom.
- 05Integrations, data and the systems around commerce.
- 06Decisions, risks, reporting and change control.
- 07Testing, launch and life after launch.
01 · Understand the business and the current position
We start by understanding how the business operates today.
This covers the business, customers, catalogue, pricing, fulfilment, internal systems, current platform and known project constraints. Depending on the project it may involve workshops, stakeholder interviews, analytics review, technical discovery, platform review, data assessment and integration mapping.
The aim is to identify what needs to change, what should remain stable and which questions need answering before delivery begins. Platform and architecture recommendations follow the operational picture rather than the other way round.
Where a brief includes work that is unlikely to pay back, we say so and explain the reasoning before it becomes part of the plan.
02 · Agree the scope and delivery plan
Scope, plan, assumptions and open decisions.
The scope sets out what will be delivered, the main assumptions, responsibilities, dependencies and acceptance criteria. The delivery plan covers sequencing, environments, data migration, integrations, testing, launch preparation and any work expected from the client or third parties.
Week 01
Business and users
Workflows, customer types, catalogue, pricing, fulfilment.
Week 02
Data review
Products, categories, customers, orders, sources and gaps.
Week 03
Integration map
The systems in and out of scope, and how data moves.
Week 04
Architecture options
Platform choice, extension points, costs and trade-offs.
Week 05-06
Plan and responsibilities
Timeline, risks, responsibilities, decisions and reporting.
Kick-off────────── Indicative 4-6 week scoping period ──────────Plan agreed
Where important information is still missing at the end of this stage, we record it as an assumption or open decision rather than treating it as settled. The plan is then used to sequence build, integration, data migration, testing and launch preparation.
03 · Team structure and who is involved
Who is involved from iWeb and from the client team.
A project team may include a delivery lead, solution architect, engineers, UX and design specialists, quality assurance, product-data specialists and support staff. The exact team depends on the scope, platform and integrations involved.
Client teams normally provide business decisions, access to systems, data, content, testing and sign-off responsibilities. Platform vendors, ERP providers, PIM teams, payment providers and other suppliers may also have defined responsibilities within the plan.
Role
On commerce
Projects
Speciality
Principal Engineer
22 yrs
41
Adobe Commerce architecture, migration, B2B
Solution Architect
18 yrs
36
PIM, ERP integration, multi-storefront
Delivery Director
24 yrs
58
Project governance, steering, escalation
Lead Engineer · API
14 yrs
27
Order, payment, fulfilment, search
Lead Engineer · Front
12 yrs
24
Hyvä, Storefront, Core Web Vitals
Data Lead
16 yrs
29
Migration, reconciliation, MDM
UX Lead
15 yrs
31
B2B journeys, conversion, account complexity
QA Lead
13 yrs
38
Release engineering, rehearsal, rollback
Anonymised roster · representative of roles active on projects shipped 2024-26.
04 · Choosing platform, extension or custom
Use the platform where it fits, extend where it does not.
For most requirements, the ecommerce platform, its extensions and its ecosystem already provide a suitable answer. Choosing that answer, and configuring it well, is often better value than building something bespoke.
Where the business needs something the platform does not do well, we extend it. Where extension is not appropriate, we build the smallest custom piece that does the job. The reasoning is documented so the trade-off is visible to the client team.
Maintainability is treated as a commercial factor: bespoke code needs to be owned and paid for over its lifetime, so we take that cost seriously when weighing up options.
05 · Integrations, data and the systems around commerce
The systems around the platform usually decide the outcome.
ERP, PIM, order management, warehouse, payments, tax, search and marketing systems typically run alongside the ecommerce platform. We document which system is responsible for products, pricing, stock, customers, orders and fulfilment, and how information moves between them. Important interfaces are agreed before they become development assumptions.
01Critical
ERP / Finance
Order-to-cash, returns, credit, GL posting.
02Critical
OMS · Order routing
Multi-warehouse, click-and-collect, drop-ship.
03Critical
WMS · Warehouse
Pick / pack / despatch, partial fulfilment.
04Critical
PIM · Product data
Attributes, taxonomy, multi-channel publishing.
05Critical
Payments
Gateways, tokenisation, B2B credit accounts.
06High
Tax · Cross-border
VAT, IOSS, US sales tax, duty calculation.
07High
Search
Algolia / Constructor / Coveo · merch rules.
08Medium
CDP / Marketing
Identity, consent, segmentation, send platform.
A typical replatform connects to between eight and twenty-four such systems. Each one is mapped during scoping, sequenced in the plan and tested against real data before launch. Phased release is used where it lowers risk or suits the business better.
31 years working in ecommerce, across replatforms, builds, rescues and long-term support.
The next two sections cover how work is scoped and how integrations, data and operational systems are handled. Both are where projects most often need attention.
600+
Projects delivered
Since 1995
Tracked
Risks and dependencies
With an owner and next action
9yr
Average client tenure
Top 10 clients
62
Team
UK based, employee owned
06 · Decisions, risks, reporting and change control
How decisions are made and how change is handled.
Projects need a clear route for decisions and escalation. We record important decisions, open questions, dependencies and risks with an owner and a next action so they can be reviewed at each checkpoint. Reporting shows what has been completed, what is next, what is blocked and where client input is needed. The format and frequency depend on the size and stage of the project.
Requirements sometimes change during delivery. When that happens, we assess the effect on scope, cost, timing and technical decisions before the change is agreed. Small changes may fit within the existing plan; larger changes are documented and agreed separately. Two questions guide who owns each call: how reversible is it, and what does it cost to undo. The matrix on the right shows how that works in practice.
Cost to undo
Cheap
Cost to undo
Expensive
Reversibility
Reversible
Decided by
Engineer
Decide and ship.
Decided by
Lead Engineer
Decide, log in register.
Reversibility
Irreversible
Decided by
Solution Architect
Decide with delivery lead, log in register.
Decided by
Steering
Escalate. Written trade-off. Approval.
Every irreversible decision is logged. Steering reviews the register at every checkpoint.
07 · Testing, launch and life after launch
Test the complete service, prepare for launch, then support and improve.
Testing covers the storefront, account journeys, integrations, data, payments, fulfilment, performance, accessibility and operational processes relevant to the project. iWeb runs technical and functional testing; client teams confirm the platform works for their business processes and sign off against agreed acceptance criteria. Issues are prioritised by severity and launch impact.
The launch plan covers final data migration, code release, DNS or infrastructure changes, payment checks, redirects, monitoring, communications and fallback arrangements. Responsibilities and timings are agreed in advance, with a clear route for handling issues during the release. After launch, the team monitors the platform, resolves early issues and completes any agreed follow-up work. Ongoing support may include releases, maintenance, performance work, integrations, monitoring and further development, and depends on the platform, trading requirements and agreed service level.
Client · top 10
Years on project
Years
18
16
British Heart Fdn
12
Average top-10 tenure · 9 yrs · 4 clients ≥ 10 years.
Support relationships often continue for several years. On many projects, the same team that delivered the replatform continues to run releases, integrations and further development. The chart above shows current tenure across the top ten client relationships.
Where replatform projects tend to overrun
Common causes of overrun, and how we plan around them.
Published post-mortems of enterprise replatform projects tend to identify the same handful of causes. The bars below compare that industry pattern with figures from our own last eight projects, taken from the internal incident register. Individual projects will vary.
Failure mode
Industry · share of overruns
iWeb · last 8
Data migration · reconciliation
62%
4%
Integration timing · ERP/OMS/PIM
54%
6%
Scope creep · undocumented
48%
3%
Performance · stability post-launch
41%
5%
Trading interrupted · revenue loss
36%
0%
Decision drift · no named owner
33%
2%
Senior turnover · post-sale
29%
0%
Governance · steering disconnect
24%
3%
Industry bars: indicative share of overruns attributable to each cause, weighted across published replatform post-mortems. iWeb bars: share of the same causes recorded on our last eight projects (internal incident register).