Work With Me

The Short Version

My time is committed — a full-time role, Code Like It's 198x, and existing clients. But I keep deliberate room for the occasional engagement, because the most valuable work I've ever done arrived unplanned: the system nobody else would touch, the migration that had been "next quarter" for two years. If you have one of those, read on.

The Work I Take

I fix things other people gave up on. The neglected Rails monolith that everyone's scared to deploy. The upgrade path that looks impossible until someone maps it out. The infrastructure migration the team keeps deferring because nobody understands the old system well enough to leave it. If your problem sounds like a liability rather than a greenfield, it's probably my kind of project.

How I Work

I write things down. Before any significant change, you get the reasoning — trade-offs, alternatives considered, risks named — in a document your team keeps. I pick boring technology, because rescued systems fail again when they're rebuilt on something fashionable. And I work towards my own exit: the engagement ends with your team able to maintain the system without me. If I'm still load-bearing six months later, I've done it wrong.

Read my principles →

What I Won't Do

I won't pitch a rewrite when a rescue will work — rewrites are occasionally right, but they're the last resort, not the proposal. I won't add microservices to solve a communication problem. And I won't ship something your team can't sustain after I leave. If I think you don't need me, I'll say so; that conversation costs you nothing.

Past Engagements

The rewrite that didn't happen. A scheduling platform's Rails monolith had been written off as legacy, with a TypeScript rewrite planned to replace it. Instead of rewriting, I mapped the upgrade path nobody believed existed: Rails 5.2 to 8.0, Ruby 2.7 to 3.4, step by step, shipping the whole way. The rewrite was cancelled, the platform picked up a thirty percent performance improvement, and "legacy liability" became "strategic asset" without a single line of TypeScript.

The migration that had waited years. An access control platform of fifteen-plus interconnected services was still running on legacy servers — the migration kept being deferred because nobody understood the old system well enough to leave it. I orchestrated the move to Docker and then Kubernetes across every service with zero downtime, including a PostgreSQL 11 to 17 upgrade with a TimescaleDB extension migration.

The migration that shouldn't happen. A client began questioning whether their container orchestration platform should be replaced with a simpler deployment tool — infrastructure I had proposed and built for them five years earlier. Rather than defend it meeting by meeting, I wrote a 60-page position paper: real ingress-layer data showing availability that exceeded every major cloud provider's published SLA, measured across tens of millions of requests, a risk assessment of what the migration would actually mean, and root-cause analysis showing the errors driving the debate were application bugs, not infrastructure. The migration was dropped, the application bugs got fixed, and the paper's cost-optimisation plan saved more per month than the migration ever would have — without touching the platform. I hold my own past decisions to the same standard I'd hold anyone else's: if the evidence had favoured migration, the paper would have said so.

Starting a Conversation

Email steve@stevehill.xyz. Tell me what the system is, what's wrong, and what you've already tried — plain words, no pitch deck. You'll get an honest answer about fit, including "you don't need me" when that's true.