What it is
The idea is small and a little stubborn: before I touch a line of implementation code, I write the plan down as a contract. Not a paragraph in a chat window that scrolls away, but a real file on disk — plans/<slug>/plan.mdx — with rendered low-fidelity wireframes for each screen state, an erDiagram for anything that touches data, a table of the files I’ll add versus the ones I already have, and the RED test list that pins the behavior I’m claiming to build. Then, when it’s all pushed, I write the mirror image: a recap that lifts the actual diff back into those same blocks and calls out every place reality drifted from the plan.
Both files stay on my machine — plans/ is gitignored in this repo — so what travels with the change is the work itself, not the paperwork. The documents are for me, and for anyone I walk through them. Staying out of git did cost me something, though: a folder full of slugs with nothing tying any of them to the change it became. So the folder carries the PR number now — plans/pr-<n>-<slug>/, renamed the moment the PR opens, since the plan is written before there is a PR to name it after.
The whole point is the gap between those two documents. A plan nobody checks against is a wish; a recap with no plan to compare to is a changelog. Put them side by side and the plan becomes something I can be held to, and the recap becomes the honest record of what actually shipped — including the parts I got wrong on the first guess. Drift is fine and expected. Undisclosed drift is the only real failure.
Why I plan before I type
If you can read this, you went looking, and I like that. The blur is not hiding a trade secret. It is hiding about ten more sections on how I plan, what the process costs me, and where I think it breaks down. I am happy to hand all of it over. I would just rather do it in a conversation than in a wall of text you skim once and forget.
The short version: I write the plan before the code, as a real file with wireframes, a data model, and the list of failing tests I am about to write. Then I write the recap from the actual diff and call out every place reality drifted. The gap between those two documents is the whole point.
Why bother interviewing me
Because the interesting part of this is not that I wrote a process down. It is the reasoning underneath it, and that comes across far better when you can push back on it in real time. Ask me why the recap earns its keep on a messy branch. Ask me where the process is overhead I have not managed to justify yet. I have answers for both, including the uncomfortable one.
I would also rather you judge me on the work than on a page that markets itself. This whole site is the artifact: the code, the tests, the history, the things I got wrong and then fixed in public. Read any of it. Then come ask me about the parts that look strange.
What I am actually good at
Shipping small, reversible changes without breaking the thing that already works. I write the test first because it is the cheapest way to find out I misunderstood the problem, and I keep the increments small enough that a bad call costs an afternoon instead of a sprint. That habit is most of what I bring.
The rest is taste about boundaries: knowing when to reuse the mechanism that exists instead of inventing a parallel one, when a type should be strict, and when a clever abstraction is going to cost the next person more than it saves me today. I care a lot about the next person, who is usually me in four months.
How I work with other people
I say what I actually did, including the parts that did not work. If I drifted from the plan I write down that I drifted and why, because the undisclosed version is the only kind that hurts anyone. I would rather deliver an honest no than a confident maybe.
I ask questions early, when they are cheap, and I would rather be told I am wrong on a wireframe than on a branch that took a week. If you want someone who will disagree with you in the planning meeting and then fully commit once it is decided, that is the way I like to work.
So, get in touch
The button below opens an email to me. There is no form, no funnel, and nothing gets collected. It is one message to one person, and I answer all of them.
Tell me what you are building and I will tell you honestly whether I am the right fit for it. If I am not, I will say so. If I am, I will walk you through the rest of this write-up and anything else you want to open up.
What I'd do now, and what I did
- Planning in a structured artefact rather than chat prose, so the plan survives the conversation and can be checked against what shipped.
- Local files only, with no hosted planning service, which was a deliberate call after a security review rather than a preference.
- A recap built from the real diff, so drift between plan and result is visible instead of quietly absorbed.
Where it could go further
- Nothing enforces that a plan was written. It is a practice I follow, and a skipped plan leaves no trace.
- Plans are untracked, so the reasoning behind a change is not in the repository with the change — deliberate, and it does mean the history is thinner than it could be. Naming each folder after its PR closes some of that gap, but the plan still lives only on the machine that wrote it.
Next on this
- Nothing scheduled. This documents a working practice rather than a system, and it changes when the practice does.