User manual
How I operate.
A short note on how I think, how I work, and what to expect if we work together.
I prefer writing over meetings, clear scope over ambiguity, and direct communication over endless politeness. If something is not working, I would rather say it early than waste time pretending otherwise.
I like fast iterations, documentation, and decisions that can be explained plainly. I do not like performative process, status theater, or dragging out obvious calls.
Principles
Boring choices are usually right. I trust proven tools over fashionable ones.
Design for failure. I care more about failure modes, observability, and maintainability than clever demos.
Technical decisions are business decisions. Architecture is never separate from economics, speed, and leverage.
Sovereignty matters. Own more of the stack when it meaningfully improves control.
Start from the real problem. I try to solve the underlying issue, not just the obvious request sitting on top of it.
If we work together
Communication is async-first. Email for new inquiries. Telegram or Slack for active work. I check messages in batches, not continuously.
Response time is usually within 24 hours on weekdays. Faster for urgent project issues. Slower when I am traveling with family.
Meetings are short and rare. If a call is needed, it should have a purpose.
You should expect directness. I will tell you what I think, not what is easiest to hear.
I optimize for fast iterations. I would rather ship, learn, and adjust than over-plan a perfect solution in theory.
Documentation matters. Decisions, rationale, and context should be written down.
No lock-in. I build things you can maintain without me.
Not a fit
I will not babysit process. If you need daily standups and ticket management, I am probably not the right fit.
I have a family. I protect my time with them fiercely. That makes me better, but not endlessly available.
I am blunt. Some people like that. Some do not.
Still interested?
See how I can help.