Most of the interesting work sits between a regulated, high-consequence domain and a person who just wants their problem to go away. My job is usually to make the second half feel simple without lying about the first.

I lean toward buying, borrowing, and gluing before I build. Every custom system is a permanent tax on the team that inherits it. When I do build, I want it small enough that one person can hold it in their head and change it on a Tuesday.

I've gotten more comfortable shipping the ugly version. Regulated products especially reward getting one real user through the flow over polishing an unstarted one — the feedback is always sharper than the plan.

And I've stopped trying to separate the engineer half from the founder half. The same instinct that makes you want to read the migration guide before writing the code is the one that makes you want to talk to the user before writing the brief.