How I build

Most builds start as something half-formed and a little too big. The first job is to make it small enough to reason about.

• Clarify the actual problem hiding under the idea — not the version that just sounds impressive.
• Name who it actually helps, even if that's only future-me at 2am.
• Define what success looks like concretely, so "done" isn't a vibe.

No six-month rewrite you have to trust on faith. The goal is the narrowest thing that does something real.

• Resist the rewrite — find the thin vertical slice that proves the idea.
• Define the next step narrowly enough that it fits in one sitting.
• Keep the work reviewable: small diffs a human (or an agent) can actually read.

Before anything touches a real system, decide how it fails safely. Automation without a panic button is just a faster mistake.

• Dry-run mode first — show me what it would do before it does it.
• Logs that mean something, so behavior is observable after the fact.
• Least-privilege permissions: scope every grant to what the slice needs.
• Rollback thinking — know how to undo it before you run it.
• Explicit confirmation on anything destructive or irreversible.

Speed comes from tight loops, not skipped steps. Every change earns its place by passing through validation.

• Validate locally — run it, watch it, don't trust it on faith.
• check / build / test as the standing gate before anything merges.
• PR summaries that explain the why, not just the diff.
• Documentation alongside the change, because if it isn't written down it isn't finished.

Shipping starts the feedback loop, it doesn't end it. The weird edge cases are where the next slice comes from.

• Watch real behavior once it's live, not just the happy path.
• Treat weird edge cases as gifts — they're the spec you didn't write yet.
• Fold what you learned into the next slice, and keep going.