I've been building software for more than 20 years, but the part that still interests me most is the beginning — when the problem is unclear, the constraints are moving, and nobody knows yet whether the idea will work.

That is where I do my best work: turning risky ideas into working systems, finding the simplest architecture that can survive reality, and implementing the parts where the real technical difficulty lives.

I care less about technology as identity and more about what can be built from it. Languages, runtimes, models, protocols, and infrastructure are tools — useful when every piece has a clear role.

unclear problem      → working prototype
risky assumption     → focused experiment
complex system       → explicit responsibilities
technical debt       → fix the foundation
"probably works"     → prove it

• I enjoy 0→1 engineering, architecture, and the hardest implementation work.
• I prefer small, technically strong teams with trust, autonomy, and real ownership.
• I prototype quickly when learning — and care deeply about quality once a direction proves itself.
• I value direct feedback, technical honesty, and solutions that are easy to reason about.
• If an approach feels unnecessarily complicated, I will probably try to remove half of it.

Core: TypeScript · Node.js · Bun · Go
Also useful: Python · Rust · Solidity
Systems: NATS · gRPC · Protocol Buffers · Docker · AWS
Data: PostgreSQL · MySQL · Redis Stack · SQL · NoSQL
Applied AI: local inference · LLM APIs · MCP · RAG · vector databases

The list changes. The preference does not: simple, fast, resilient systems with every component earning its place.

I'm especially interested in early-stage products where there is still something fundamental to discover — a difficult technical constraint, an unusual system to design, or an idea that looks impossible until it works.