Selection principle
I do not chase tools for their own sake. I care more about whether a tool reduces friction, stays understandable, and continues proving useful over time.
Uses
Uses
The hardware, software, tools, and working preferences behind the way I build. This page is less about showing off a setup and more about keeping a practical record of what actually earns its place.
How I choose tools
Workflow fit
The best tools tend to disappear into the workflow rather than asking to be admired constantly.
Standard
If a tool increases complexity without increasing capability, it does not stay.
Current setup
- My setup changes when the work changes, but the standard stays similar: enough power to build seriously.
- Enough simplicity to remain usable without constant maintenance overhead.
- Enough flexibility to support both practical output and longer experiments.
- A tool does not need to be impressive. It needs to keep helping after the novelty wears off.
Workflow preferences
System posture
- Direct: fewer abstraction layers between intent and output.
- Inspectable: systems should be readable and debuggable without ceremony.
- Easy to live with: maintenance burden matters as much as launch speed.
Technical defaults
- Static where it makes sense: simple publishing paths and durable surfaces first.
- Local where trust matters: keep sensitive or reliability-critical workflows close to the machine.
- Complexity only when earned: added moving parts must prove long-term value.