Code Health Check

Find out what needs fixing before you build on it.

Your app runs, but you need to know whether its code can support real customers, another developer, or the next release. I review the codebase and return an evidence-backed list of risks and remediation priorities.

Two-week diagnostic · Scope and price agreed before work starts

Request a Code Health Check →

I’ll reply by email to discuss fit and scope. This requests a conversation; it does not book an appointment.

When this review helps

  • You’ve shipped quickly with AI agents and need an independent assessment of the code.
  • A handover or upcoming release has exposed questions about security, tests, or architecture.
  • You need to decide which repairs are worth doing before committing to more development.

What you receive

Findings with evidence
Each finding identifies the affected behavior, supporting evidence, confidence, and likely consequence.
Ranked remediation priorities
A practical order for addressing critical risks, quick wins, and work that can wait, with recommended next steps.
A written report and walkthrough
A report your team can work from and a conversation about the findings, tradeoffs, and unanswered questions.

Scope, access, and timing

We agree on the repository, critical workflows, and review boundaries first. I’ll ask for read-only repository access, setup instructions, and a safe way to exercise the agreed workflows. Please don’t send credentials through the inquiry form.

The diagnostic takes two weeks once the agreed access is available. The review covers code quality, security risks, and maintainability within that scope. Implementation, a full penetration test, and compliance certification are separate work.

You receive a fixed quote before we begin. The price depends on the size of the codebase, access, and the workflows we agree to assess. If remediation needs hands-on support, we can scope a Vibecode Rescue afterward.

Example finding

Illustrative sample, not a finding from a client engagement.

A background job can process the same payment twice

Evidence and confidence
A staging test retries the same event and creates two records. High confidence in the reproduced behavior; production impact remains unverified.
Priority and consequence
Address before enabling retries for this workflow. A transient failure could cause a duplicate charge.
Recommended action
Define an idempotency key, enforce it at the persistence boundary, and test repeated and concurrent delivery.
Acceptance check
Delivering the same event twice produces one payment record and one external charge.

For examples of my public review method, read the product audits. Those use public surfaces; a Code Health Check adds the repository access needed to investigate internal behavior.

Discuss your codebase

I led technology and product at Humi through its $140M+ CAD acquisition. My work spans two decades of shipping software, including payroll and other systems where correctness matters. More about my background.

Request a Code Health Check →