Company

How we work

Seven phases that suit problems which need diagnosing before they can be fixed — and how the sequence changes when the problem is an outage, a search collapse, an AI build or a platform at capacity.

The sequence

Seven phases

Ordered deliberately, and the order is usually what determines whether the work holds. Diagnosis before architecture, baseline before change, monitoring after.

Discovery
Establish what the system actually does, as distinct from what it is documented to do. Access, constraints, prior attempts, business consequences and the boundary of what is in scope. The output is shared understanding rather than a proposal.
Diagnosis
Find the actual constraint. This is the phase that distinguishes our work from a recommendation, and it is where most of the value is created — the reported symptom is frequently two layers above the cause, and fixing the reported symptom is expensive and ineffective.
Architecture
Decide what to change and at what level. A template defect is fixed in the template; an infrastructure defect is fixed in the infrastructure. Getting this wrong produces work that has to be repeated, so the level of the fix is decided explicitly rather than by convenience.
Implementation
Make the change. On live systems this is incremental, with rollback available and validation in production — there is no maintenance window on a platform with users.
Validation
Confirm the change did what it was intended to do, measured against a baseline captured before the work began. Without a baseline there is no evidence, only an assertion, and a baseline cannot be reconstructed afterwards.
Monitoring
Instrument what was fixed so a regression is detected rather than reported. In several disciplines — performance and search especially — the natural direction of travel is backwards, and monitoring is what prevents that.
Continuous improvement
Re-diagnose as the system changes. Infrastructure that was correct at one scale is not automatically correct at the next, and discovery behaviour that was optimal for one content estate may not suit the next.

Variations

How the sequence changes by engagement type

A single process applied uniformly to an outage, an AI build and a search collapse would be wrong in all three cases. These are the differences that matter.

AI engineering engagements

Weighted towards the front. Failure-mode analysis and evaluation design precede implementation, because the cost of discovering a quality problem after launch is far higher than the cost of defining what 'good' means first. Implementation is iterative against the evaluation set rather than against a specification.

Search engineering engagements

Weighted towards diagnosis and verification. Search infrastructure responds slowly and partly, so the sequence includes an explicit monitoring window after implementation — and reporting separates what was changed from what moved, because conflating those is how search work becomes unfalsifiable.

Infrastructure and performance engagements

Weighted towards measurement. The baseline is captured first, under realistic conditions, and every change is validated incrementally in production. Capacity work adds a modelling step so the client can predict the next constraint rather than discovering it.

Recovery engagements

Sequence inverted. Stabilisation comes first, before diagnosis is complete, because a platform that is failing has a higher cost of continued failure than of a temporarily suboptimal fix. Full diagnosis and durable remediation follow once the platform is up.

Retained engagements

Discovery is repeated rather than completed. The value of a long relationship is accumulated context about how a specific system behaves, which is what makes fast diagnosis possible — and it is why our longest engagements have run for years rather than months.

Working with us

Delivery, governance and expectations

The practical questions that come up once an engagement is being assessed seriously — including the ones where the answer is a limitation.

Senior involvement throughout

The engineers who scope the work deliver it. There is no handover from a pre-sales team, because the person who understands the constraint is the person who should be acting on it.

Documentation as a deliverable

Findings, decisions and the reasoning behind them are written down. This matters most in search and infrastructure engagements, where a large part of the output is defect documentation precise enough for another team to act on.

Confidentiality

Non-disclosure terms apply throughout delivery, communication and access management. Public engagement profiles use an anonymised client descriptor only when the agreement permits it.

Change control

Changes to live systems follow the client's change-control process, including their approval gates and release windows where those exist. We do not work around a client's process to move faster.

Security and access

Least-privilege access, scoped to what the engagement requires, and revoked at the end of it. Credentials are handled through the client's own secret management wherever one exists.

Communication

Written, asynchronous and specific by default, with scheduled calls where a discussion is genuinely faster. Engineering problems are better documented than discussed, and a written record is what makes an engagement reviewable after the fact.

Regulated project fit

If an engagement requires a specific certification or regulated control, we confirm that requirement during qualification so the delivery model is suitable before work begins.

Handover

Every engagement is designed to leave the client able to operate what we built. A dependency that exists because something was not explained is not a business model we want.

Output

What exists at the end of an engagement

If an engagement ends with nothing written down, it has not really finished.

During an engagement

Written findings and constraint analysis
Decision record with reasoning
Baseline measurements taken before changes
Defect register with severity and state
Change log against the client's process

At handover or review

Before-and-after measurements under matched conditions
Architecture and configuration documentation
Operational runbooks where applicable
Monitoring and alerting in place
Open items with an assessment of each

In practice

Where this process was applied

Two engagements with very different shapes — one a recovery, one a long-running infrastructure relationship.

Fintech & capital markets

Search engineering at stockbroking scale

A stockbroking platform publishing at news velocity was losing search visibility to problems that had nothing to do with content quality. Two workstreams ran in parallel: sustaining a high-volume editorial output across business and market categories, and diagnosing the technical faults — a domain safety flag, recurring server errors, and a metadata defect on a templated page type — that were suppressing how much of that output search engines could actually reach.

225Msitewide impressions

Online communities

Arrse.co.uk

An established community platform had accumulated three separate problems that compounded each other: page loads that had degraded with growth, search visibility that had not kept pace with the community's authority, and a security posture that had not been revisited as the platform's profile grew. The engagement addressed all three concurrently.

4%increase in organic clicks

Questions

Frequently asked

How quickly can you start?

For recovery engagements, immediately — a failing platform does not wait for a discovery phase. For planned work, the constraint is access and the people who need to be involved rather than our availability, and both are usually established in the first conversation.

Do you require a long commitment?

No. Focused projects and diagnosis-only engagements are both available and are often the right first step. Retained work exists for clients who want continuous operation, but it is not a prerequisite for working with us.

What happens if you cannot fix it?

You get the findings, the tests performed and the remaining uncertainty. If the problem needs a different specialist, the diagnostic record gives that person a concrete starting point instead of forcing the investigation to begin again.

How do you handle a system you have not seen before?

By reading it. The accumulated experience that matters most here is not familiarity with a specific codebase but the ability to establish how an unfamiliar system behaves under load, and where its constraints are. That is the same method every time, applied to a different system.

Start with a problem, not a specification

Most engagements begin with a diagnosis. That is usually the right first step and it is available on its own.

Discuss your engineering challenge View our work

Contact

How we work

Seven phases

Discovery

Diagnosis

Architecture

Implementation

Validation

Monitoring

Continuous improvement