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.

Hands-on Engineering

This is the most flexible way to work together. I join a product team or agency as a hands-on principal software engineer.

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.

What rescue looks like

One product team was drowning in work after building fast. Its Next.js app spanned Vercel, AWS, Terraform, RDS, and DynamoDB. Local onboarding and provisioning were fragmented, while deployments relied on a manual rsync process across unrelated development, staging, and production branches.

In under four weeks, while continuing to ship product work, I built a reproducible local environment, added a full CI gate, automated staging deployments, added guarded production releases, and made it possible to refresh staging with sanitized production data.

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 one-page triage: fix this week, fix this quarter, and leave alone. We talk through the findings before the written report, including work I can take on without interrupting your team’s sprint.

For a Rails app, this is how I work through the first week.

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

What clients notice

“An extraordinary thing happened when Ally joined our team: everyone got more productive. Her thoughtful code reviews and kind guidance were a force multiplier. Her in-depth knowledge of Postgres, Ruby, Rails, and AWS were on display as she confidently led multiple successful platform transitions without disrupting customer activity.”

Aaron Gerdes, Lead Engineer at Rosh Review

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.

Start with what’s stuck

Send me a note about what you’re trying to ship and what keeps getting in the way. The stack and the part your team is nervous to touch are useful context. You don’t need to send code or production data.

We’ll talk through the blocked work and decide where I can help. Before starting, we’ll agree on the first piece of work and what done looks like, whether that’s a feature shipped, a deployment the team can repeat, or an audit with a clear first priority.