Skip to content

Available for new engagements

Software built well, and proven to work.

I'm Josh — a consultant working across the whole software lifecycle. Product development, test automation, CI/CD, and AI-leveraged delivery that speeds the work without lowering the bar. One engineer, accountable end to end, in your codebase rather than beside it.

Tools I work in every day

  • TypeScript
  • React
  • Next.js
  • Node.js
  • Playwright
  • Appium
  • GitHub Actions
  • Docker
  • Postgres
  • Vercel
  • Claude Code
  • MCP

AI-leveraged delivery

Where AI actually helps

AI is doing real work in engineering right now, and it is also being sold as the answer to problems it doesn't solve. Knowing the difference is most of the value.

Delivery speed, with the review gates intact

AI drafts quickly and confidently, including when it's wrong. Used well, it compresses the time from intent to a reviewable pull request — and everything it produces still goes through the same tests, review, and CI as anything hand-written. Faster drafts, identical bar.

The repetitive middle of QA

Generating cases from a spec, triaging a wall of failures, clustering flake by root cause, keeping selectors current as the UI moves. This is work that scales badly with people and well with automation. What to test, and whether a failure matters, stays a human call.

AI features you can actually evaluate

If you're shipping something built on a model, it needs an evaluation harness the same way code needs tests. Without one you're changing prompts and hoping. I build the harness so you can tell whether a change helped, regressed, or did nothing.

And where it doesn't: anywhere a confident wrong answer costs more than a slow right one. Compliance logic, data migrations, security boundaries, anything a regulator will read. I'll tell you when that's the situation rather than selling you tooling for it.

Approach

How the work actually runs

Three commitments that hold on every engagement, whether it's a two-week assessment or six months of delivery.

  1. 01

    Understand before changing

    Every engagement starts by reading the code, the pipeline, and the bug tracker. Recommendations come after evidence, not from a template. You get a written summary of what I found — including the parts that are already working well.

  2. 02

    Ship in small, visible increments

    Work lands in reviewable pull requests against a backlog you can see. No months-long silence followed by a big reveal. You can stop, redirect, or reprioritise at any point without losing what has already been delivered.

  3. 03

    Leave it maintainable

    The goal is a codebase your team owns, not a dependency on me. That means documentation, conventions that match your existing stack, and a handover where your engineers can walk through the work and change it confidently.

Engagement models

Ways to work together

Pick the shape that matches the problem. Assessments often turn into projects; projects often turn into ongoing support — but none of that is assumed up front.

Assessment

1–2 weeks

A focused review of your codebase, test suite, and release process, ending in a written report and a prioritised roadmap. A good starting point if you know something is wrong but not what.

Project delivery

Typically 4–12 weeks

A defined scope with a clear finish line — a test suite built, a pipeline rebuilt, a product feature delivered end to end. Fixed scope, regular demos, working software at each step.

Fractional / ongoing

Monthly, rolling

Part-time senior capacity embedded with your team — reviewing, building, and raising the engineering baseline over months rather than weeks. Cancel or pause with notice.

Let's talk about what you're building

A short conversation is usually enough to work out whether I can help, and what the first useful step would be. No pitch deck, no obligation.