Before an acquisition or investment
A buyer or investor needs an independent view of the code and the team, beyond what the current owners report.
Package
Know the true state of your software.
A focused review of the code, the delivery process and the way the system runs, ending with a plain report on what is healthy, what is fragile and what to fix first.
Duration2 weeks
FormatFixed-scope technical review
Best forTeams inheriting or scaling a system
OutcomeRanked risks and a fix plan
Overview
An honest read, without the alarm.
Every codebase carries history: rushed releases, abandoned plans, a dependency nobody wants to touch. Much of that is normal. The problem starts when nobody can tell the difference between ordinary wear and a fault that will surface at the worst moment. The health check exists to draw that line clearly, using evidence from the code and the people who maintain it.
We read the code, run the build, review the tests and deployment, and speak to the engineers on the ground. We look at how work reaches production and how quickly problems are found. The result is a short list of risks, ordered by impact, with the effort each fix would take.
Codebase review by senior engineers
Experienced engineers read the code with an eye for coupling, duplication and the places changes are likely to break.
Delivery and testing review
We follow a change from commit to production and check whether tests, reviews and releases match the risk.
Infrastructure and cost review
We inspect hosting, cloud configuration and running costs, looking for both fragility and money spent for no benefit.
Interviews with your team
The people who maintain the system know where it hurts, and their account shapes the findings.
Risks ordered by impact
Findings are ranked by how much they threaten delivery or stability, not by how interesting they are technically.
A plan you can budget for
Each recommended fix has a rough size and sequence, so the report can feed straight into planning.
Use cases
When a health check helps
Useful before a major investment, after a difficult period or whenever the system feels harder to change than it should.
After a difficult release
A serious outage or a string of bugs has shaken confidence, and you need to know whether the cause is local or systemic.
A team change
The original developers are leaving or have left, and the remaining team needs a map of what it is inheriting.
Rising cloud or maintenance costs
Spend and maintenance effort keep climbing without a clear reason, and you want the causes identified before cutting anything.
Deliverables
What you receive.
- A written review of the codebase
- A delivery and testing assessment
- An infrastructure and cost review
- Interview notes from your engineering team
- A risk register ordered by impact
- A rough size and sequence for each fix
- A readout session with your team
How we work
The two-week review.
Days 1 to 2: Context
We meet your team, agree the systems in scope and gather access to the repository, pipelines and monitoring.
Days 3 to 6: Code and delivery
We read the code, run the tests and trace how a change moves from review to production safely.
Days 7 to 8: Operations and interviews
We review hosting, costs, incident history and the concerns raised by the engineers who do the work day to day.
Days 9 to 10: Report and readout
We write the findings, rank the risks and walk your team through the report and the recommended order of work.
FAQ
Common questions.
Will you fix the problems you find?
Only if you want us to. The health check is a review, and the report stands on its own. If you want, we can take on the first fixes afterwards.
Do you need full access to production?
Read access to code, pipelines and monitoring is usually enough. We work within your security rules and can sign an NDA before access is granted.
How disruptive is the review?
Most of the work happens away from your team. We ask for a kickoff, a few interviews and a readout, and we keep requests to the people who know the system.
Is the report technical or for management?
Both. Each finding has a plain summary for decision makers and enough detail for engineers to act on it.
Can you review a system we did not build?
Yes. Most reviews cover code written by another team or an earlier vendor.
Next step
Start the conversation
Would an outside view help right now?
Tell us what has been happening with the system. We'll say whether a health check is the right step and what access it would need.