Modernisation & Consulting

Technology Consulting

An honest read on what you have and what to do next.

Most technical decisions are made with incomplete information about the current state. A team knows the system is slow, or fragile, or expensive, but not precisely why — and without that, the choice between fixing, rebuilding and replacing is a guess.

We do focused technical assessments: reading the code, running the system, examining the infrastructure and the deployment process, and reporting what is actually there. The output is written down in terms a non-technical decision-maker can act on, with the technical detail available underneath.

This work is deliberately separable from building. The assessment is useful on its own, and it is yours regardless of what you decide to do with it.

At a glance

Typical stack: Laravel AWS Docker
Common industries: SaaS & Startups
Engagement: Fixed scope, dedicated team, or staff augmentation

Request a quote

No obligation. We will tell you if it is not a fit.

The problem

What this solves

Assessments are often done by the party who wants to win the rebuild, which makes the recommendation predictable. The finding that a system is basically sound and needs three specific fixes is commercially inconvenient for whoever is quoting for a replacement.

The other problem is depth. A review that only reads documentation and interviews the team reproduces what the team already believes. The things worth finding — the undocumented dependency, the backup that has never been restored, the credential in the repository — are found by looking.

Decisions made without a baseline

Choosing between fixing and rebuilding without knowing what is actually wrong.
Assessments with a commercial answer

A review by the party quoting for the rebuild rarely concludes that a rebuild is unnecessary.
Reviews that only read documents

Interviewing the team reproduces the team's existing beliefs rather than testing them.
Findings nobody can act on

A severity label without a consequence does not help anyone prioritise.

Our approach

How we go about it

We look at the system itself: the code, the dependency versions and their support status, the database and its query patterns, the infrastructure and how it was created, the deployment process, and the monitoring. Where possible we run it and exercise it rather than reading about it.

Findings are separated into what is urgent, what is important, and what is merely untidy — and each one gets an estimate of consequence rather than just a severity label. "This will stop receiving security patches in four months" is actionable in a way that "outdated dependency" is not.

The recommendation is whatever the evidence supports, including that the right move is to change nothing, or to spend the money on something other than software.

Capabilities

What is included

Architecture and codebase review
Technology selection and trade-off analysis
Security and performance assessment
Delivery planning and estimation
Team structure and process advice
Vendor and platform evaluation

Outcomes

What changes for you

Based on the system, not the story

Code read, infrastructure inspected, deployment and backups actually exercised.
Prioritised by consequence

Each finding carries what happens if it is ignored and roughly when.
Written for the decision-maker

A summary a non-technical reader can act on, with the detail underneath for the team.
Yours either way

The report is a deliverable, not a sales document, and it does not depend on us doing the work.

Related work

Where we have done this

All case studies

Frequently asked questions

Common questions about technology consulting.

What does an assessment cover?

Scoped to your concern, but typically: code structure and quality, dependency and framework versions against their support windows, database design and query behaviour under real data, infrastructure and how reproducible it is, deployment and rollback, backups and whether they restore, monitoring, and the obvious security exposures. If you have a specific worry we weight towards it.

Will you recommend rebuilding?

Only if the evidence supports it, which is less often than the industry suggests. Most systems that feel unmaintainable have a small number of specific problems — a missing test suite, a handful of pathological queries, an unrepeatable deployment — and fixing those is dramatically cheaper and less risky than starting again.

Do we have to use you for the work afterwards?

No. The report is written to be actionable by your own team or another supplier, and that is a deliberate choice. An assessment that only makes sense if we do the work is not an assessment.

Related services

Not sure whether to fix it or replace it?

That question is usually answerable in a couple of weeks of looking properly. The answer is yours either way.

Start a project Talk to our team