What I help with
I focus on the problems that reward experience and judgment rather than raw effort — the ones where understanding the system correctly is most of the battle. The work is diagnosis: figuring out what's actually wrong before anyone commits time and money to a fix.
Database Performance
Queries that have grown slow as data and load increased. Indexing and schema decisions that no longer fit how the application is actually used. The gap between "it worked fine at launch" and "it's a problem now."
Databases don't get slow once — they get slow again as a company grows, and telling a slow query from a schema problem from a capacity problem is most of the work. This has been a through-line of my work for two decades, including the platform behind one of the world's largest casting databases.
The deliverable is a clear read on where the time is actually going and a recommended path forward — sometimes a substantial change, sometimes a small one that resolves most of the pain.
Complex System Troubleshooting
Production problems that resist the obvious explanations: intermittent failures, performance that degrades under conditions no one has pinned down, behavior that doesn't match anyone's mental model of the system.
Finding the real cause is usually the hard part; the fix tends to follow from it. This is the kind of work that rewards having seen the failure modes before rather than raw effort — and it's the corner of the field least exposed to automation. A tool can write a function. It can't walk into a system that's falling over in production and work out why.
You get a level head while the system is down, and an honest account of what's actually happening rather than the first plausible theory.
Inherited & Overgrown Codebases
Systems that have outgrown the team's full comprehension of them — through turnover, age, or organic growth. The work still gets done, but it gets harder, slower, and riskier, and the cost of a wrong guess keeps rising.
I'm unusually good at coming into a large, unfamiliar codebase and developing an accurate picture of how it actually works — not how it was meant to work. That comprehension is the prerequisite for every safe decision that follows: what can change, what's load-bearing, and where the real risk sits.
The result is a map of the system you can trust, and a clear-eyed view of your options before anyone commits time and money to a fix.
Technical Strategy & Architecture Review
Decisions that are expensive to get wrong and difficult to reverse: whether to rebuild or repair, how to plan a migration off a system you've outgrown, where the real risks sit in an architecture, and what a sound path forward looks like.
This includes software business strategy, where the technical and business questions are tangled together — and technical due diligence for investors who need a read on a system backed by a long, verifiable track record.
The advice is independent. If the right answer is to repair rather than rebuild, or to keep the system you have, you'll hear it. You're paying for an accurate answer, not a recommendation shaped to maximize the engagement.
How engagements work
Most engagements start the same way: a conversation about the system and what's going wrong, followed by a focused assessment. The goal of that assessment is a clear, honest picture of the problem and a recommended path forward — including, where it's the right answer, the option that costs you the least.
I try to be direct about trade-offs rather than selling a predetermined solution. Sometimes the right recommendation is a substantial piece of work; sometimes it's a small change that resolves most of the pain; sometimes it's that the system is fine and the problem is elsewhere. You're paying for an accurate answer, not a foregone conclusion.
When a diagnosis leads to implementation work, that building is handled through Durable Programming, a separate firm where I work with a small team of full-stack engineers. You can engage me purely for diagnosis and strategy, take the plan to your own team, or have Durable carry it out. The choice is yours, and there's no assumption that an assessment turns into a larger project.
Who this is for
A good fit
- Teams facing an acute, high-stakes technical problem — a performance crisis, a mysterious production failure, a system nobody fully understands
- Organizations weighing an expensive, hard-to-reverse decision: rebuild or repair, migrate or stay
- Investors needing technical due diligence backed by a long, verifiable track record
- Anyone who values independent counsel over a vendor's pitch
Not the right fit
- Anyone who needs a large delivery team from day one — Durable Programming is the better door
- Buyers shopping purely on hourly rate
- Routine, preventative maintenance sold cold — that's not the problem this practice is shaped to solve
- Work outside my areas of genuine expertise — I'll tell you, and point you somewhere better
Also available
Conference talks, user-group presentations, and technical writing. Books and articles have appeared in Dr. Dobb's Journal, Linux Magazine, IBM DeveloperWorks, and PHP International Magazine, distributed in more than 65 countries.