Product Engineering
An engineering partner for the whole product lifecycle — discovery, architecture, build, and the unglamorous work of keeping it healthy after launch.
Explore this serviceTechnical Consulting
An honest second opinion, in writing
Sometimes the expensive decision is not the build — it is whether to build at all, whether the system you have can carry two more years, or whether the team telling you it can is right. We do the assessment, put it in writing, and give you the reasoning rather than a verdict.
- Written deliverable
- No obligation to build
- Evidence over opinion
Engineering advice is only worth something when the person giving it has recently done the work and has nothing to sell you. Our consulting engagements are deliberately separable from our build work: the deliverable is a document you own, and a recommendation to change nothing is a legitimate outcome.
What we assess
We read the code, the schema, the pipeline and the incident history — then talk to the engineers who live in it. Assessments that skip that last step tend to mistake unfamiliar decisions for bad ones.
What you get
A written report: what is load-bearing, what is genuinely risky, what is merely unfashionable, and a sequenced plan with effort estimates. Sized so an engineering lead can act on it and a board can read the summary.
- Architecture and code review with a prioritised risk register
- Technical due diligence for investment or acquisition
- Build-versus-buy and platform decisions, argued with numbers
- Team and process review — where the delivery friction actually is
Problems we solve
What this work is for
The situations teams are usually in when they bring us this problem.
Nobody independent has looked
The people who built it are the only people assessing it. Not dishonesty — just proximity. A second read is cheap.
Rewrite or refactor?
The most expensive question in software, usually answered by whoever argues hardest. We answer it with evidence.
Diligence before a deal
You are about to buy or fund a codebase. You need to know what you are actually acquiring, in plain language.
Our approach
How the work runs
The same sequence on every engagement, so there are no surprises in week three.
Scope
We agree the questions you need answered and what a useful answer looks like. Vague scope produces a vague report.
Investigate
Code, schema, pipeline, incidents, and interviews with the engineers. One to three weeks, typically.
Write it up
Findings, evidence, risk ratings, and a sequenced plan with effort estimates — not a list of opinions.
Walk it through
A session with your team and, where useful, your board. The report is meant to be argued with.
What's included
What you get
Concrete deliverables — all of it yours to keep, run, and hand to another team.
Written assessment
The document, with evidence and reasoning — yours to keep and to share.
Risk register
Prioritised by business impact, not by how much it offends an engineer's taste.
Sequenced plan
What to do, in what order, with effort estimates and the cost of doing nothing.
Walkthrough
A working session with the people who have to act on it.
Follow-up
A review a quarter later, at no cost, to see whether the plan held up.
Technology
What we build it with
Chosen for the problem, not for novelty.
We are not tied to any of these. If your team already runs something that works, we build with it.
- Review
We read what the system actually does — the code, the schema and the production data, not the diagram.
- Code review
- Schema review
- Incident history
- Interviews
- Evidence
Claims about performance and reliability are checked against telemetry, not accepted as folklore.
- Field data
- Load testing
- Query analysis
- Bundle analysis
- Deliverable
A document with reasoning, so a decision can be revisited when the facts change.
- Written report
- Risk register
- Roadmap
- Estimates
Questions
Before you get in touch
The questions that come up in almost every first conversation.
Will you recommend we hire you?
Only if that is genuinely the answer, and we will say plainly when it is not. Several of our assessments have concluded that the existing team should do the work, with a plan for how. The report is written to be useful even if you never speak to us again.
How long does an assessment take?
One to three weeks depending on the size of the system. Due diligence under deal pressure can be compressed, and we will tell you what that costs in depth.
What do you need from us?
Read access to the repositories, the incident history, and an hour each with a few engineers. We work around your team rather than through them.
Tell us what you're building.
Bring the problem, not a spec. We will tell you honestly whether we are the right team and outline a concrete first step — no obligation, no sales theatre.