I work with a small number of early-stage teams — usually on something they are about to build, or something they have just discovered does not scale.
What to build now versus what to defer, and which of the shortcuts you are considering will still be fine at fifty times the volume. Most early systems do not fail because the code was bad; they fail because a boundary was drawn in the wrong place while it was still cheap to move.
What I work on →The point where informal stops scaling — when nobody is sure which decision was already made or where it was written down. What to formalise, what to leave alone, and how to introduce a process that survives the week after you introduce it.
How I lead →Moving past autocomplete to agents with defined roles, a written backlog and guardrails that reject work which breaks the design. I run this on my own projects, so what I bring is tested rather than read.
How I run it →It starts as a conversation. You describe the problem, I tell you whether I am actually the right person for it — sometimes the answer is no, and that is a faster result than a proposal.
After that it is shaped around what the problem needs: a single session to work through a decision, a short review of an architecture or a process, or a standing call while something is being built. Everything is arranged directly with me.
This runs alongside a full-time engineering role, so I take on a few engagements at a time and I am careful about what I say yes to. I am most useful early — while decisions are still cheap to change — and least useful as an extra pair of hands.
Write to tkumar.savani@gmail.com with a couple of lines about the problem. That is genuinely enough to work out whether it is worth a call.