How I work

A fixed-scope audit, with a written findings document

This is the low-risk first step, and the one I recommend for almost everyone. I read the codebase and the infrastructure around it, map how it’s put together, and grade what’s there: architecture, maintainability, test coverage, data security, deployment, and the operational process around all of it.

You get a written document, addressed to you, that says what’s sound, what’s risky, and what I’d fix first and why. If the codebase turns out to be in good shape, the document says so. That’s a perfectly good outcome, and I’ll tell you if it’s the one you have.

The audit is fixed in scope, so you know what it costs before it starts, and it gives us both a clear picture before deciding whether there’s a larger piece of work to do.

A defined statement of work, with deliverables and a timeline

When there’s a specific outcome to reach, we write it down first. A statement of work names the deliverables, the timeline, what I need access to, and what done looks like, before any code changes.

Typical projects: hardening an AI-assisted application for its first real customers; putting monitoring, alerting, and a deployment pipeline under a system that has none; and standing up data infrastructure that has to keep working while everything around it changes.

Ongoing senior engineering capacity for a team that can’t hire it yet

Some startups need a senior engineer on hand more than they need a project. Retained availability gives you a standing block of my time each month for whatever matters most then: reviewing what the agents wrote before it ships, answering the on-call question nobody else can, planning the next piece of infrastructure, or pairing with the one engineer you do have.

This shape works best once we’ve completed at least one engagement together and both know what to expect.