[ The offer ]
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.
Read access only. Nothing on a running system is changed.
Three depths
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.
01 · Triage · 1 day
A findings note and a judgment on whether a full check is warranted.
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.
02 · Health Check · 1–5 days
The full report — risk register, system map, verdict and a priced roadmap.
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, priced by the size and complexity of the system. Everything below assumes it.
03 · Deep Assessment · 2–4 weeks
The full report, an integration map, and migration or consolidation feasibility.
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.
Prices for all three depths are on one page
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.
What gets inspected
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.
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.
Whether a repository exists, whether the deployed artifact matches it, whether a clean machine can produce a working build, and who owns the code.
Language and framework versions against vendor end-of-life dates, dependency ages, and whether an install still resolves today.
Hosting, patch level, certificate renewal, DNS, and whether deployment is a script or a person connecting over SSH.
Schema, growth, retention, where copies live — and a restore actually performed during the engagement, not a backup log read.
Authentication, secrets in source, injection surface, known vulnerabilities, admin routes reachable from the open internet, and whether authorization is enforced or merely hidden.
External systems, API versions against published deprecations, token and certificate expiry, and behaviour when a dependency is simply unavailable.
Whether a test suite exists and still runs, the observable defect list, error rates, and the workarounds staff have quietly adopted.
Logs and their retention, monitoring, alerting, and who the alerts actually reach.
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.
Hosting, licences, seats, third-party services, over-provisioning, and subscriptions still billing for something switched off long ago.
How long a small change takes, how many people it involves, and the list of requests already abandoned.
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.
How findings are ranked
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.
Already costing money, or one ordinary event away from a serious outage — an expiry, a disk filling, a single unreachable person.
DECIDE THIS QUARTERWill 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 BUDGETNo 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 ROADMAPEvery 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 conclusion
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.
Sound enough to keep. Work the risk register and leave the architecture alone.
The 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.
Buy time first, then replace in phases behind a stable exterior. The most common honest answer.
The cost of changing it now exceeds the cost of rebuilding it. Said plainly, with the arithmetic.
The 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 saysreplace, 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.
The same four stages apply whether the capability is pricing, invoicing or a report nobody can change.
What we take on
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. The highlighted ones have a page of their own.
Afterwards
Rescue and modernization are scoped from the report, not before it.
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.
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.
Scope boundaries · before we start
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.
What you will need to provide.
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.