1
Triage
A three-to-four page findings note and a judgment on whether a full check is warranted.
Access — None. External observation and one interview.
Credited in full against a health check booked within 30 days.
Software Health Check
A paid, fixed-scope inspection of a system your business already depends on. You get a written report you could hand to a different developer tomorrow and still get value from — which is the only thing that makes the findings worth believing.
Start at the level of access you are comfortable giving.
The usual reason a conversation like this stalls is not price. It is that a stranger has asked for the keys to the system the business runs on. Triage requires nothing but a conversation and what is publicly visible.
2
Health Check
The full report — risk register, system map, verdict and a priced roadmap.
Access — Read access to source, hosting, database and logs. One system.
The core engagement. Everything below assumes it.
3
Deep Assessment
The full report, an integration map, and migration or consolidation feasibility.
Access — As above, across several systems and the integrations between them.
For a business running three or four systems that disagree with each other.
A fixed price assumes the fixed scope is reachable, so the engagement is scheduled from the date the access checklist below is complete — not from the date the invoice is paid.
Thirteen domains.
Each one is a question you can answer without being an engineer, and a set of things we actually look at. If you already know the answer to three of these and it worries you, that is the finding. The last one is the odd one out: its answer is an opportunity rather than a risk, and it is what decides whether a bypass is on the table.
B.01
If you had to change one line tomorrow, who could?
Custody of every credential the system depends on — registrar, DNS, hosting, repository, CI, certificates, third-party keys, and the mailbox that receives the password resets.
B.02
Can this be rebuilt from what you own?
Whether a repository exists, whether the deployed artifact matches it, whether a clean machine can produce a working build, and who owns the code.
B.03
How long until the ground it stands on is withdrawn?
Language and framework versions against vendor end-of-life dates, dependency ages, and whether an install still resolves today.
B.04
What does a deploy actually consist of?
Hosting, patch level, certificate renewal, DNS, and whether deployment is a script or a person connecting over SSH.
B.05
If the database vanished at 2am, what comes back?
Schema, growth, retention, where copies live — and a restore actually performed during the engagement, not a backup log read.
B.06
What is exposed, and to whom?
Authentication, secrets in source, injection surface, known vulnerabilities, admin routes reachable from the open internet, and whether authorization is enforced or merely hidden.
B.07
What breaks when somebody else changes something?
External systems, API versions against published deprecations, token and certificate expiry, and behaviour when a dependency is simply unavailable.
B.08
What is it getting wrong today?
Whether a test suite exists and still runs, the observable defect list, error rates, and the workarounds staff have quietly adopted.
B.09
How would you find out it broke?
Logs and their retention, monitoring, alerting, and who the alerts actually reach.
B.10
What obligations does this system carry?
Dependency licences against commercial use, an inventory of the personal information held and the Law 25 duties attached to it, payment data and the PCI scope it drags in.
B.11
What is being paid for, and is it needed?
Hosting, licences, seats, third-party services, over-provisioning, and subscriptions still billing for something switched off long ago.
B.12
What does the business want to do that the system prevents?
How long a small change takes, how many people it involves, and the list of requests already abandoned.
B.13
Where can this be tapped without opening it up?
Every point something new could read from or write to without editing the application: a database view or read replica, an export, a file drop, a scheduled job, a queue, a webhook, a reporting account. This is the domain that decides whether a bypass is possible at all, and it is the only one whose answer is an opportunity rather than a risk.
Severity, expressed as time rather than adjectives.
Critical, high, medium and low is a scale for engineers. You budget in quarters, so ours is temporal — three bands, each naming when the decision is actually due.
Now
Already costing money, or one ordinary event away from a serious outage — an expiry, a disk filling, a single unreachable person.
Decide this quarter
Soon
Will bite within twelve months on a schedule someone else controls: end-of-life, a certificate, an API sunset, capacity. Predictable, and therefore budgetable.
Put it in next year's budget
Structural
No deadline at all. This is why change is slow and expensive, and it compounds quietly. The band most often ignored, and most often the real reason you called.
Decide with the roadmap
Every finding carries evidence — a file, a version, a log line — what happens if nothing is done, and an effort band of hours, days, weeks or months. Never an hour count: false precision on a system we have looked at for two weeks would be quoted back at us for the rest of the engagement, and it should be.
The report commits to one of five verdicts.
This is most of what you are paying for. An inventory of everything wrong with a codebase is worth very little — you already suspect most of it. The value is in the ranking and in someone being willing to say which of these it is.
- StabilizeSound enough to keep. Work the risk register and leave the architecture alone.
- BypassThe problem is real and the system is not worth opening. A new service takes the load; the old one keeps running and keeps its job.
- Stabilize, then modernizeBuy time first, then replace in phases behind a stable exterior. The most common honest answer.
- ReplaceThe cost of changing it now exceeds the cost of rebuilding it. Said plainly, with the arithmetic.
- RetireThe system outlived the process it served. Sometimes the answer is a spreadsheet and a subscription.
Sometimes the honest verdict is retire — that the system outlived the process it served, and the answer is a subscription and an afternoon of data migration. Because the check is already paid for, we can say that and still get paid. If it were free, there would be quiet pressure to find a verdict that sells work, and you would have no way to tell the difference.
The third way
Sometimes the right move is to route around it.
A problem can be bad enough to deserve fixing and still not be worth opening the system to reach. There is no budget for a rewrite; or the thing runs the business and nobody sane touches it on a Tuesday; or it is genuinely annoying without being expensive enough to justify the risk of surgery.
So we build a small service beside it and route the traffic through that. Think of a highway with a section under repair: the lane closes, a relief road opens, the traffic merges out and back in. The road underneath is not dug up and it is not demolished. It carries on doing the part of the job it still does well.
Concretely: one capability moves out of the legacy system into something new and small that we own end to end. The old system reads from it — through a database view, an export, a scheduled job, whatever seam B.13 found — and otherwise carries on untouched. No code inside it changes. If the new service stops, the old behaviour is still there to fall back to.
Why this is the one we can price up front
A rescue is repair work on a system nobody has fully read, so an honest quote carries irreducible uncertainty — which is why it is scoped from the report rather than guessed at beforehand.
A bypass is not that. It is a new build against a known interface: we choose the stack, we write all of the code, and the surface area is set by the seam rather than by whatever is waiting inside fourteen-year-old source. That uncertainty is simply absent, so the price is fixed and it can be quoted on the call after the readout.
What has to be true before we recommend it
- There is a seam. If the only way in is to edit the application, this is not a bypass — it is the in-place change you were trying to avoid, wearing a different name.
- One system owns the truth. The moment the same fact can be written in two places you need a rule for which wins, in writing, before anything is built. Most bypasses that fail do not fail technically; they fail on whose number is right.
- It is permanent by design, or it has a sunset date. On a real highway everyone knows the detour is a detour. The failure here is the cones staying up for ten years until the relief road is load-bearing, undocumented, and the second legacy system. Either it is the system of record from cutover — fine, and we document and support it — or the report names the condition under which it comes out.
- It is a cure, not just relief. There are cases where routing around a problem lets a business defer a replacement that is genuinely overdue. When that is what is happening the report says replace, not bypass.
There is a worked example in the sample report — the pricing rules that exist twice, moved into one service both systems read, with neither of them rewritten.
- 01
The system
One capability inside it is the problem. Everything either side of it is doing its job and has been for years.
- 02
The seam
B.13 finds where the system can be read from without being opened — a database view here, a linked table there. No code is edited to create them; they already exist.
- 03
The bypass
A small service takes the load and the old section closes. Traffic merges out at one seam and back in at the other. Nothing inside the original changes.
- 04
Still there
The road underneath was never dug up. If the bypass stops, the barriers come out and the old path carries traffic again — which is why this is the low-risk answer.
If it runs your business, it qualifies.
Whatever it was written in. The list below is what we see most; it is not a limit.
Access databasesExcel / VBA workbooksPHP applicationsWordPress and its plugins.NET FrameworkClassic ASPJava (Struts, early Spring)Python 2 and early 3Node.js that stopped buildingFileMakerDelphi and VB6Broken integrations of any kind
Rescue and modernization are scoped from the report, not before it.
Software Rescue is the stabilization pass: recover source and access, fix the failures that wake you up, close the security holes, and put backups, monitoring and documentation in place. Two to eight weeks, quoted against the risk register once it exists.
Modernization replaces pieces of the old system while it keeps running — one module, one integration, one screen at a time, each phase independently valuable and independently stoppable. You must be able to do phase one and then decline phase two without having wasted the money.
None of the three is sold as a big-bang rewrite. Two of them are not priced before the diagnosis — that is not caution, it is that any number offered before reading the code is invented.
What the check is not.
Stated here, in the proposal, and on the first page of the report. Declaring non-goals plainly is what keeps a fixed-price diagnostic from expanding into an unbounded one.
- Not a penetration test, and not a security certification. Security is inspected as posture, from the inside, in the time bought.
- Not a line-by-line code review. The report reasons about structure, risk and cost, not style.
- No changes are made to any running system. Read access only, unless remediation is agreed separately in writing.
- Not a guarantee that every defect has been found. The report reflects what was visible in the time bought, and says how much time that was.
- Not a legal or accounting opinion. Licence and privacy findings are flagged for your professionals, not resolved by us.
What you will need to provide.
- Read access to the source repository, or the source files themselves if there is no repository.
- Read access to the hosting or server environment, and to the database.
- Log access covering at least the last thirty days.
- A list of the third-party services the system uses, and who holds each account.
- Thirty minutes each with two people who use the system daily — not only whoever commissioned it.
- Any documentation, agreements or invoices relating to whoever built it.
If some of this does not exist — no repository, nobody who knows the hosting password — that is not a problem with your request. It is the first finding, and Triage is designed for exactly that case.
Start here
Tell us what is not working.
A short description is enough to tell us which depth fits. If it is not a fit, we will say so — that is a cheaper answer for both of us than a proposal.