"What exactly does your health check look at? Are you going to look at it and just say we need to rebuild?" Let's answer the second question first: whether a rebuild gets recommended, you won't know until it's done — but out of the three possible conclusions, "recommend rebuilding" is actually the least common one. The reason people ask this is that handing your code to a stranger to review is inherently risky — if all you get back is "this is beyond saving, let us rebuild it," you've just paid for nothing. You're not being overly cautious — nobody ever told you in advance what we actually look at. Here are the four areas that make up the entire health check.
Why we won't quote without looking first
Two systems can both be called "a website," but the monthly effort required after taking one over can differ by several times over:
- One with backups, documentation, and a repeatable deployment process — most of the time, just keeping an eye on it is enough.
- One that's just a zip file, with the password only in the previous engineer's head — every single change means an excavation first.
- Quoting without looking: quote too high and you overpay; quote too low and we want to give up halfway through — either way, you end up paying for it.
That's why the health check is a mandatory first step before working together. We don't take on anyone who wants a quote without a health check first.
How the health check works, and what you need to prepare
The whole process isn't long, and it asks less of you than you'd expect.
| Stage | What we do | What you need to prepare |
|---|
| Before | Confirm the system's type and scope, quote the health check fee | Where the system runs, roughly what features it has |
| 60-minute online meeting | Review the code together, ask about the current state and where it hurts | Let us see the code — no production credentials needed |
| 3–5 business days after the meeting | Review each of the four areas one by one | Nothing to do — just wait for the report |
| Delivery | A one-page report and one of three conclusions | Review it, then decide whether to work with us |
Priced based on system size, with no contract required — the report is yours, and you're free to take it and ask someone else.
Areas one and two: is the code readable, and can the data be moved
Code isn't graded on how well it's written — it's assessed on "how long would it take whoever takes over to start making changes":
- Whether version history exists, and whether you can see who changed what and when.
- Whether the structure follows a pattern: similar things grouped together, one feature changed in one place.
- Whether the technology used is still maintained, and whether its vulnerabilities are still being patched.
The database gets scrutinized even more closely than the code, because code can be rewritten, but data can't be redone:
- Whether automatic backups run on a schedule, and whether the backup is stored somewhere other than the server itself.
- Whether field names are meaningful, and whether the same type of data exists in only one place.
- Whether sensitive data is protected: whether passwords are stored irreversibly, whether the database is exposed to the entire internet.
If an engineer just left, these two areas are usually the biggest question marks. The 12 things to get back first after an engineer leaves is exactly the material worth gathering before a health check.
Areas three and four: can deployment be redone, and are the doors locked
Deployment is the process of getting code from an engineer's computer onto the production server. Whether this process can be redone determines whether the system can be saved when it breaks:
- Whether the steps are written down anywhere. If it only lives in someone's head, it counts as not existing.
- Whether a bad change can be rolled back to the previous version within minutes.
- Whether, if the entire server disappeared, it could be rebuilt from the code, config files, and backups.
Security isn't a penetration test — we don't simulate attacks. We only check the three most basic, highest-consequence doors:
- Whether permissions are actually separated: not shown on screen doesn't count — it only counts if the backend checks it too.
- Whether keys are written into the code, and whether they've ever entered a repository. If they have, they're treated as leaked.
- When security updates stopped, and whether any known vulnerabilities are still open.
Our system operations handoff guide covers the full process once we take over; this part of the health check only checks whether the handoff material actually exists.
What you get: a one-page report, one of three conclusions
Keeping the report to one page is deliberate: an owner can read it start to finish, every sentence lands on a conclusion, and there's no jargon piled on top. It covers the status of each of the four areas, the three things that most need fixing first, and one of three conclusions:
- Ready to take over as-is: the fundamentals are there, and basic maintenance can start right away.
- Needs cleanup first, then takeover: the code is workable, but backups, deployment, or security have gaps that need fixing before it can run properly in production — quoted separately based on condition.
- Rebuilding is recommended: we'll tell you directly, and tell you exactly what has to be preserved if you rebuild. The logic behind this call is covered in four criteria for save versus rebuild.
Three principles we follow when running a health check
- We don't touch your production environment: we only need to see the code, no credentials to your production environment required.
- No contract, no assumed answer: we take on long-term relationships, so we have no incentive to push you toward rebuilding.
- We quote only after looking: once we're working together, basic maintenance starts at NT$6,000/month, billed monthly, and you can stop anytime.
Look first, talk about money after — that order is fairer to both of us.
The health check is the first step whenever we take over a system as Helper CTO — like an in-house tech lead, just not on your payroll, with takeover, maintenance, and improvement only discussed once we've looked closely. The entire health check is a 60-minute online meeting — we only need to see the code, no credentials to your production environment required — and within 3–5 business days you'll get a one-page report you can actually understand. If you want to know where your system stands across these four areas, you can start here: Helper CTO: System Maintenance Plan.
Technical Sharing
