When do you need a Targeted Intervention?

When one specific part of the software is blocking everything else: a prototype that doesn't scale, a fragile component, or a technical bottleneck slowing down delivery for the whole team.

How long does a Targeted Intervention take?

The intervention is surgical and focused. How long it takes depends on how complex the problem is, but the goal is always a concrete result, as quickly as possible.

Do you work on legacy code too?

Yes, when the problem is a single bottleneck: we stabilise the critical part without rewriting everything. If, on the other hand, the debt is spread across several areas of the code, the starting point is a technical debt assessment. It tells you whether you need a legacy code refactoring programme or a Targeted Intervention on a single spot, or whether your team can carry out the resulting plan on its own.

How do you work out where to step in?

We analyse the architecture, the delivery pipeline and the dependencies between components to find the exact point where the system gets stuck. The intervention targets the real bottleneck.

There's a part of your software that's slowing down your growth

We work on prototypes that don't scale and technical bottlenecks
that block delivery

If any of these signs sound familiar, it isn't a people problem

Every change introduces regressions

Estimates are unpredictable

The team avoids certain parts of the codebase

Features take longer than expected

The roadmap keeps slowing down for technical reasons

It's an unresolved technical bottleneck

Why it happens

When a product grows too fast, parts of the system become rigid

Not because of incompetence

Not because of carelessness

But because:

Technical decisions made under pressure become permanent

Architecture that evolves without ongoing refactoring builds up compromises

Boundaries between components become blurred

New features get built on foundations that are already fragile

At first it works

Then every change costs more than the last one

order_manager.js — 847 lines

function processOrderV2_FINAL_fixed(o, ctx, flag) {

// TODO: work out why flag=2 breaks everything — don't touch

if (o.type != 'B' && flag !== 2 && ctx.user.role !== 'admin') {

var res = db.query(`SELECT p.*, d.val, COALESCE(d2.override_val, p.base) as eff FROM pricing p LEFT JOIN disc d ON d.oid=${o.id} AND d.active=1 LEFT JOIN disc_override d2 ON d2.pid=p.id WHERE p.sku=${o.items[0].sku} AND p.region=${ctx.region || 'EU'}`)

if (res[0].eff * 1.22 > o.total && !o._skip_check) {

sendMail(ctx.user.email, 'ALERT', res)

updateLegacyERP(o.id, 3, ctx)

// not sure what flag 3 does in the ERP

} else if (o.total === 0 || o._legacy_import) {

db.query(`UPDATE orders SET status=99 WHERE id=${o.id}`)

// status 99 = ??? see slack #ops-2021

}

var tmp = calcDiscount_NEW(o, res, true)

if (tmp2 != null) notifyAll(tmp, ctx.user, o)

// tmp2 isn't defined here — but it never crashes in prod

refreshCache_v1()

refreshCache_v2(o)

// call both, order matters (nobody knows why)

}

⚠ every change here takes hours of analysis just to work out what not to break

It isn't chaos. It's unmanaged complexity

Surgical intervention. Clear scope

We don't rewrite everything

We don't stay forever

We identify the critical point and work on that

Targeted technical audit

Bottleneck identification

Opportunistic refactoring

Stabilisation

Ongoing knowledge transfer to the team

We unblock the part that's slowing down everything else

What we don't do

We don't rewrite everything from scratch on principle

We don't make you dependent on us

We don't add complexity where it isn't needed

We don't sell open-ended refactoring

We only step in where the impact is greatest

The goal isn't to change everything

It's to regain control where things are fragile today

How we work out where to step in

Before we touch the code, we analyse the system

We look at:

Coupling points between components

Circular dependencies and high-volatility areas

Parts with insufficient test coverage

Flows that generate frequent regressions

Areas where changes have a disproportionate impact

We don't step in where it's most visible

We step in where the effect is systemic

// dependency map — billing module

module: billing

depends_on:

- pricing

- notifications

- reporting

volatility_score: high

test_coverage: 42%

// high systemic impact

That's why the intervention is targeted

After the intervention

The code becomes easy to change again

Estimates become more reliable

Less firefighting

More stable delivery

A more predictable roadmap

order.service.ts

- function updateOrder(order) {

- recalculatePricing(order)

- notifyWarehouse(order)

- syncCRM(order)

- updateAnalytics(order)

- }

+ function updateOrder(order) {

+ pricingService.update(order)

+ eventBus.emit('order.updated')

+ }

// isolated responsibilities, controlled effects

Growth no longer stalls because of a technical problem

It's the right time if:

You're scaling and something has seized up

The initial prototype can't take the strain any more

You've inherited a complex legacy codebase

The team is stuck on a critical part

Don't wait until it becomes unmanageable

If the problem isn't a single bottleneck but debt spread across several areas of the code, the first step is a technical debt assessment; from there, if needed, you move on to a legacy code refactoring programme.