How I Approach Building
I build naive first. Not because it’s optimal — because watching something fail under real constraints is the fastest way to understand where the complexity actually lives.
Before I reach for a framework, I want to know what it’s hiding. Before I optimize, I want to know what’s breaking and why.
Most of my work starts the same way: build the simplest version possible, push it until it breaks, then trace the failure back to where the real cost lives.

↓ the full process