Early in a product, a few decisions are cheap to change for a few weeks and then, quietly, permanent: the architecture, the way the team works, what the agents are allowed to do. I help early-stage teams look hard at those while changing them still costs an afternoon.
By day I lead an engineering team on large-scale attribution infrastructure, the kind of system where being wrong is invisible and correctness has to be engineered in. On my own time I build an independent product with agents as the delivery team, and I run an experiment in handing agents the whole loop rather than the coding step.
So the outside view comes from someone still inside the work. I am not reporting what I have read. I am telling you what broke last month and what I did about it.
Founders and small engineering teams at the point where the next few decisions will set the shape of everything after them. Usually before there is a platform team, often before there is a second engineer, and almost always before the thing that looks fine today has been asked to do fifty times more.
You do not need to know what kind of help you need. A decision you are about to make is enough to start with.
Not coding assistants. Agents with defined roles, working from a written backlog with acceptance criteria, behind checks that reject anything breaking the design. I have run my own product this way for months, and most of what I have learned is about the guardrails, not the prompts. If you are deciding how far to let agents in, that is the conversation I most want to have.
How I run it →What to build now and what to defer, and which of the shortcuts on the table will still be fine at fifty times the volume. Early systems rarely fail because the code was bad. They fail because a boundary was drawn in the wrong place while it was still cheap to move. By day I work on a system where a wrong answer looks exactly like a right one, which changes what you are willing to call a shortcut.
The systems I work on →The point where informal stops scaling: 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. I lead my own team this way, process over presence, and never a reminder where a check would do.
How I lead →You write to me with the decision. The first conversation is about whether I am actually useful for it, and sometimes the answer is no, which is a faster result than a proposal. After that the shape follows the problem: one session to work through a decision, a short review of an architecture or a process, or a standing call while something is being built. There is no package, and nothing is arranged through anyone but me.
This runs alongside a full-time engineering role, and that is a feature rather than a footnote. I take on a few engagements at a time, so I have no reason to make a problem larger than it is, and no reason to say yes to one I cannot help with. I do not take work that overlaps with my employer’s business, and I do not become a second engineer for a quarter. What I do is look at decisions, early, while they are still cheap, and tell you what I actually think.
If there is a decision like that in front of you, write to info@tsavani.com. A couple of lines about it is enough to tell whether a call would help. The worst outcome is a quick, useful no. There is also a short form.