Bring me the work holding your team back.

Teams usually call me after their developers have said some version of: “We can’t build this before we do this, and this, and this.”

Sometimes the trigger is a failed deployment or production downtime. More often, the team is simply struggling. Deadlines keep slipping because every feature exposes another prerequisite, another brittle system, or another part of the app nobody feels comfortable changing.

They usually know where the bad code is. What they need is a senior engineer who can get into it, separate expensive problems from harmless ugliness, and start making progress without turning cleanup into its own year-long project.

Most engagements start with real work, not a formal audit. I join the team, pick up something useful, and learn the system by shipping.

Embedded Engineering

This is the most flexible way to work together. I join a product team or agency as a senior engineer who can operate independently.

Give me a feature nobody has time to own, a difficult bug, an infrastructure problem, or the hard corner everyone keeps working around. I take responsibility for getting it done. While I’m there, I fix whatever is making the rest of the team slower.

I work best with teams that trust me to spend time on those problems when I find them. That might mean improving local development, tightening CI checks, fixing the deployment pipeline, or bringing another engineer into a difficult area so they can own it afterward.

Codebase Rescue

Codebase rescue is for teams already drowning.

Features are blocked behind prerequisite chains. Deploys fail or need babysitting. The same modules keep causing bugs. Developers know what hurts, but the roadmap leaves no room to fix it.

I work incrementally and keep product work moving. A rescue might include making local development reliable, untangling a core workflow, rebuilding CI/CD, stabilizing production, or handling an upgrade nobody else feels confident touching.

Fractional CTO

I help founders and engineering leaders choose a stack, make architectural decisions, build the right team, evaluate hires, and decide where engineering time should go. It’s the same judgment I bring to hands-on work, focused on technical direction and team effectiveness. This can stay advisory or include implementation when that’s useful.

Focused Codebase Audit

An audit makes sense when the team agrees something is wrong but can’t agree on where to start.

I read the code, infrastructure, test suite, and deployment process, then talk with the people working in it. You get a short set of priorities: fix now, fix later, and leave alone.

If the next move is already obvious, we can skip the report and start fixing it.

What the first week looks like

I usually grab a few smaller issues the team needs done but doesn’t have capacity to take on. I start pushing PRs in the first few days. Those issues expose the same tension the team feels every day, which gives me a better map than reading the repository in isolation.

Then I fix the biggest obstacle I find. The team should feel relief quickly, even when the larger cleanup takes longer.

I leave stable ugliness alone. I focus on the code and process that keep showing up in estimates, incidents, and conversations.

You work with me

You work directly with me from the first conversation through the engagement. If you want more engineers involved, I have people I trust, but expanding the team is a decision we make together.

The best fit is a team that wants more than extra ticket capacity. You want someone to make an impact, challenge decisions when needed, and leave the codebase easier for your team to own. Everyone doesn’t need to agree on every solution. They do need to be willing to work together.

I’m based in Southeast Asia, a US citizen, and work remotely with US and international clients.