Technical Health Check
A plain-English report of the risks, and what to fix first.
- How long1 to 3 weeks
- How we workFixed package
What you receive
An outside engineer looks under the bonnet of your software and tells you, in plain English, what is fine, what is fragile and what to fix first.
Is the code in good shape?
You receiveCode and architecture review
You learn whether new features will stay quick to add or keep getting slower and riskier.
What it is. We read the code and the overall design: how it is organised, how easy it is to change, and where it is tangled.
Why it matters. You learn whether new features will stay quick to add or keep getting slower and riskier. That shapes every plan you make.
What are we relying on that we do not control?
You receiveDependency and licence check
Old libraries are a common way in for attackers.
What it is. A list of the outside libraries your software uses, how out of date each is, and any licence terms that could cause trouble.
Why it matters. Old libraries are a common way in for attackers. Licence surprises can block a sale or an investment.
Are we paying for more than we use?
You receiveInfrastructure and cost review
Most systems we review carry unused or oversized services.
What it is. A look at your servers, cloud accounts and services: what is running, what it costs each month, and what could be smaller or simpler.
Why it matters. Most systems we review carry unused or oversized services. Savings here often pay for the review itself.
How exposed are we?
You receiveSecurity findings
You hear about the gaps from us, not from an attacker.
What it is. The weak points we found, such as open services, weak sign-ins, unpatched software or secrets left in code, each with how serious it is.
Why it matters. You hear about the gaps from us, not from an attacker. Each one comes with a fix.
Why is it slow, and will it cope with growth?
You receivePerformance findings
Speed affects sales and staff time every day.
What it is. Where the system spends its time, what slows pages and jobs down, and what would break first under more users.
Why it matters. Speed affects sales and staff time every day. You know what to fix before growth turns slowness into outages.
Is the way we work helping or hurting?
You receiveTeam and process notes
Most risk is in how software is changed, not only in the code.
What it is. Notes on how changes are made, tested and released, and on knowledge that lives in one person's head.
Why it matters. Most risk is in how software is changed, not only in the code. Small process fixes often prevent the biggest incidents.
What should worry us most?
You receiveA red, amber and green risk register
You see the whole picture on one page.
What it is. Every finding in one table, rated red, amber or green, with what it could cost you if left alone.
Why it matters. You see the whole picture on one page. Board members and non-technical owners can follow it too.
What do we fix first?
You receiveA prioritised fix plan
Your team or ours can start straight away, on the work that removes the most risk for the least effort.
What it is. The fixes in order: what to do this week, this quarter and later, with a rough size for each.
Why it matters. Your team or ours can start straight away, on the work that removes the most risk for the least effort.
Can you explain it to us?
You receiveA walkthrough session
Your people understand the findings, not just receive them.
What it is. A session with your team going through every red and amber item and the reasons behind the plan.
Why it matters. Your people understand the findings, not just receive them. That makes the fixes far more likely to happen.
From brief to done
- 1
Week 1
Access and read
We get read-only access, read the code and look at the infrastructure.
- 2
Week 2
Test and measure
Security, performance and dependency checks, and conversations with your team.
- 3
Final days
Report and walk through
The risk register and fix plan, presented to your team.
Is this idea worth building, and where do we start?
Idea to first step. A one-page brief for your idea: the problem, who it is for, the smallest useful first release and the risks.
- A 30-minute call about the idea and the people it is for
- A one-page brief you can share with a co-founder, a board or another supplier
- It is free. There is nothing to pay and nothing to sign.
- The report is yours to keep and share, whatever you decide.
- No sales call unless you ask for one.
Questions people ask
How much does it cost?
We send a written quote after your request: what it covers and what it does not. The tier, scope and timing set the price.
Could I just use AI for this?
AI drafts code and prototypes quickly, and we use it every day. It cannot decide what to build, prove that it is secure, or answer for it when real people rely on it. That is the part you are hiring us for.
Who owns the work?
You do. Code, designs, files and documents are yours, and the quote says so in writing.
Can we change the scope?
Yes. If something needs adding or removing, we agree it in writing before we do it.
What happens after?
Most people go on to Fractional CTO, but there is no obligation. You keep everything we made.