Who this is for
- Founders who inherited a codebase from a previous CTO, an acquired startup, or an agency that's no longer responsive.
- New CTOs in month one who need to give the board an honest answer to "is this thing salvageable?"
- Series A teams whose MVP is now load-bearing and the technical debt is starting to slow feature work.
- Operators who bought a SaaS and need to know what they really acquired.
The symptoms that mean you need this
- Every deployment feels like a coin flip.
- Nobody on the team can explain the data model end-to-end.
- Tickets that look small consistently take days.
- There's a folder called
old/,tmp/, orv2/that everyone is afraid to touch. - The README is wrong. The
.env.examplefile is half the truth. - Auth, billing, and admin panels each look like they were written by a different person — because they were.
- There are at least two competing patterns for the same thing (state, HTTP, auth, error handling).
What the diagnostic delivers
01 — Honest rewrite-vs-refactor verdict
For each subsystem (auth, billing, core domain, admin, frontend shell, data layer) — keep, refactor in place, or replace. With reasoning. Not "we should use the modern stack" but "this subsystem costs you X engineer-weeks per quarter because of Y, and Z would change that."
Full rewrites usually fail. The verdict reflects that. Replace is only recommended when the cost of staying is provably higher than the cost of leaving.
02 — Stabilization roadmap, prioritized by revenue impact
The parts of the system that touch payments, signups, retention, and core user actions get fixed first. Internal tooling and admin UI come later. You should never be doing a "tech-debt sprint" that doesn't have a revenue justification.
03 — "Smallest set of changes that buys the most safety"
A short list — usually 6 to 12 items — of high-leverage changes you can ship in the first 30 days. Things like: turning on a single observability tool, adding one critical test, deleting a dead service, locking a dependency, isolating one risky integration behind a feature flag.
04 — Risk register the board can read
Plain-language list of "things that could fail in production this quarter," ranked by likelihood × blast radius. Not a code review — a decision document.
05 — Capability map of the current team
Who on your team can own which part going forward, what skills you'd need to hire for, and what you'd need to outsource. Without this, even a good roadmap won't get executed.
How the two weeks look
- Day 1: kickoff call. Repo access, infra access, deployment access, observability access (or lack of it — that's also data).
- Day 2–4: read the code. Run it locally. Break it on purpose. Trace one full user flow end-to-end.
- Day 5–6: interviews with whoever's still on the team. The undocumented invariants always live in someone's head.
- Day 7–9: subsystem-by-subsystem analysis. Auth, billing, core domain, data, frontend, deploy pipeline, observability.
- Day 10–11: draft verdicts and roadmap. Sanity-check the numbers.
- Day 12–13: write the report. Risk register. Capability map.
- Day 14: 90-minute walkthrough. You, your team, your board if you want.
What I don't do
- I don't recommend rewrites by default. They almost always cost more than the original estimate and ship later than the patient version.
- I don't dunk on the previous team. Most "bad codebases" were rational responses to constraints I wasn't there for.
- I don't pretend tools fix culture problems. If the real issue is that nobody is responsible for the system, no roadmap will save you. The report will say so.
After the diagnostic
You can take the roadmap and execute it with your own team — that's the cleanest outcome. Or, if you want one party accountable, The Gyld (my Athens studio) executes the high-priority items with me staying on architecture and reviews. Either path is in the report.
Frequently asked
How is this different from a code review?
A code review tells you what's wrong line by line. A rescue diagnostic tells you what to do about it — which parts to stabilize first, which to throw away, how to keep shipping revenue while you decide, and who on your team can own what.
Will you tell me to rewrite everything?
Almost never. The diagnostic looks for the smallest set of changes that buys you the most stability. Replace is only recommended when the cost of staying is provably higher.
Do you need full repo access?
Yes. Plus production observability (logs, metrics, error reporting) if any exists, and read access to your deployment pipeline. NDAs are standard and welcome.
What does "production-grade" really mean here?
It means: a teammate could be paged at 3am and know what to do. Most inherited systems fail this test in at least one place.
Want an honest read on what you actually inherited?
Tell me what you took over, when, and what's making this urgent. I'll reply within two business days.
Email Eirini → Back to main site