Diagnose before prescribing. Decide before building. Verify before leaving.
Understand the product pressure. Choose the right move. Verify it. Leave the system easier to own than I found it. Below is the operating rhythm I actually run.
Six moves, in order. Not a six-step consulting framework.
Sometimes I run all six in a week. Sometimes I live in step 01 for two sprints. The order is what matters diagnose before you prescribe, decide before you build, verify before you leave.
- 01Read
Diagnose
I read the product, repo, architecture, business goal, and current pain before prescribing a solution.
- 02Read
Prioritize
Not every problem deserves immediate refactoring. I separate critical risks from expensive noise.
- 03Read
Decide
I make tradeoffs explicit: speed vs maintainability, monolith vs split systems, manual v1 vs automation, custom build vs SaaS.
- 04Make
Build or Rescue
I implement, refactor, or guide the build depending on the engagement and the product pressure.
- 05Make
Verify
I look for evidence: tests, deployment checks, data validation, logs, screenshots, QA paths, and code review.
- 06Leave
Hand Off
The output should be understandable by founders, future engineers, and AI coding agents.