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

Most commerce projects drift before they fail.
We come in calmly, and put them back in control.

Rescue isn't about blame. It's about restoring clarity, governance and delivery confidence on projects that have stalled, slipped or become operationally exposed. We've seen the pattern before, and we know how to stabilise it without breaking what's still working.
Contents · 9 sections
  1. 01Most projects drift before they fail.
  2. 02The platform is not always the problem.
  3. 03Rescue starts with clarity.
  4. 04Stability comes before scale.
  5. 05Commerce problems surface operationally.
  6. 06Technical debt compounds commercially.
  7. 07Governance reduces recovery time.
  8. 08A national B2B distributor, project stabilised in a quarter.
  9. 09Common questions.
01 · Drift

Most projects drift before they fail.

Confidence rarely drops in one event. It erodes. Timelines slip a week at a time, dependencies move quietly, ownership blurs as people rotate, and workarounds accumulate until the original plan no longer matches the work being done.
By the time a project is openly described as in trouble, the underlying drift has usually been visible for months. Steering reports stay green, trading reports start to disagree, and the release notes get shorter.
Delays are symptoms. We start by separating the symptom from the cause, in writing, before recommending a single change.
2-4w
Triage window
To written remediation plan
~60%
Outside the platform
Of issues found, typical
90d
Stabilisation
Before any new roadmap
Stabilise
Before replatform
Rescue first, rebuild only when needed
02 · Diagnosis

The platform is not always the problem.

On most rescue engagements, roughly sixty per cent of what's wrong sits outside the platform. Governance gaps, unclear ownership, integration sequencing, fragmented decision-making, requirements that were never agreed in writing, and customisation that has accumulated without a steward.
We don't open with a recommendation to replatform. We open with a diagnosis. Sometimes the platform is a poor fit and we'll say so. More often, the platform is doing what it can inside a project that hasn't been set up to let it succeed.
03 · Triage

Rescue starts with clarity.

You can't stabilise what nobody fully understands. The first two to four weeks are an architecture review, a delivery and dependency audit, and an operational walk-through with the people who actually run the day. We listen first, in confidence, before we write anything down.
The output is a written remediation plan. It names what's stable, what's at risk, what we'd stop, what we'd sequence next, and what we'd leave alone. It isn't a pitch for further work. Some clients implement it themselves, and that's the right outcome where it fits.
04 · Stabilise

Stability comes before scale.

Before new features, redesigns or the next phase of the platform, we restore the basics. Predictable releases. Reliable integrations. Clear ownership. Operational confidence on the trading day. A new roadmap is the second conversation, not the first.
2-4 wks
Triage
4-6 wks
Stabilise releases
6-8 wks
Reduce operational risk
4-6 wks
Restore predictability
2-4 wks
Roadmap reset
Engagement start────────── typical 90 days to stable ──────────Roadmap reset
We don't pause trading. Stabilisation runs alongside the business, not on top of it. Most clients see release confidence return inside the first month, and the wider operational picture settle within the quarter.
05 · Operations

Commerce problems surface operationally.

Catalogue inconsistencies, failed fulfilment, integration timeouts, customer service pressure, reporting that doesn't reconcile. The technical cause is often small. The operational cost rarely is.
We sit with merchandising, customer service, finance and the warehouse early. Most of the meaningful signal is there, and most of the meaningful fixes need their input. Confidence is operational; it returns when the people running the day can see the platform behaving predictably again.
06 · Debt

Technical debt compounds commercially.

Fragile customisation, undocumented logic, accumulated workarounds and quiet vendor sprawl all share one property: they get more expensive every quarter they're left alone. Release risk rises, support cost climbs, and the next change takes longer than the last one of the same size.
We name the debt that matters, in writing, and sequence it against trading priority. Not all of it is worth paying down. The judgement is which parts are blocking the next twelve months of business decisions, and which parts can wait.
07 · Governance

Governance reduces recovery time.

Rescue isn't a war room. It's sequencing, accountability and controlled remediation. We replace heroics with a structure that names the owner of every decision and the deadline by which it has to be made.
The work is deliberately unglamorous. The projects that recover fastest are the ones where governance is restored before scope is reopened. New ambition is welcome in the second quarter.
08 · Proof
09 · Questions we get asked

Common questions.

What counts as a rescue?

A live site or in-flight project that is slipping, unstable, over budget or stuck. Common patterns: a replatform that has lost momentum, a Magento site degrading in production, or an ERP integration that has stalled.

What is the first step on a rescue?

A written remediation plan, not a sales meeting. iWeb spends the first one to two weeks reading the code, integrations and tickets, then writes down what to fix first, what is safe to defer, and what needs replacing.

Can you rescue a stalled Adobe Commerce or Magento project?

Yes. Adobe Commerce and Magento are where most rescue work happens. iWeb has senior engineers who have shipped on both for over a decade and can pick up the codebase without a long discovery phase.

Will iWeb work alongside the incumbent agency?

Yes, where that is the client's preference. Rescue does not have to mean replacing the incumbent. The remediation plan names the work and who is best placed to do each part.

Does rescue mean a full rebuild?

Not usually. Most rescues stabilise the existing platform first, then plan the larger change separately. A full replatform only follows when the current stack genuinely cannot support the business.

How long does a rescue engagement usually last?

The first one to two weeks produces the written remediation plan. Stabilisation work then runs for several weeks to a few months depending on the severity. A rescue rarely ends at the plan; it ends when the platform is operating to a defined standard.

Which platforms and systems do you rescue?

Adobe Commerce and Magento are the most common rescue subjects, alongside the ERP, PIM, search and middleware integrated with them. The principle is the same on other commerce platforms where the architecture and operational fit support it.

Will the rescue make things worse before it makes them better?

No. The first month is deliberately conservative on change: stabilise first, ship larger changes only when the platform can take them. The plan names what is safe to defer.

Who inside the business should bring iWeb in for a rescue?

Usually a CTO, head of ecommerce or board sponsor. By the time a rescue is needed the situation is operational and commercial, not only technical, so the conversation needs to involve someone who can act on either side.

How is rescue work priced?

The first phase, the remediation plan, is fixed scope. Stabilisation work that follows is usually a retainer or contracted statement of work, sized to the plan rather than to a default template.

More rescue support

Find the right rescue route.

Different problems need different levels of intervention. Our rescue pages cover failed builds, agency handovers, technical audits, platform issues, integrations, checkout, performance, product data and B2B trading problems.

Explore the rescue suite
Next step

Regain control of the project. Stabilise first. Decide the rest in writing.

Send the brief, in confidence. You'll get a written response from a senior expert, the shape of a triage, the risks we'd look at first, and a stabilisation plan we'd stand behind. Most rescue work runs under NDA.
Talk to an expert, in confidenceor read how we triage a project →