One email per milestone
3 Aug 2026
Say you want "an HMI" for your machine, and that's the whole spec. No forty-page document, no ticket board. That's not an edge case; it's what real work looks like when you hire someone to own the problem rather than execute a document. Here's the mechanism I use to keep that kind of work from spiralling — and what it looks like from your side of the table.
The one email
I split the work into milestones so it can't spiral. At the start of each milestone I send a single email. One. It contains:
- Everything I might need this phase.
- The risks I already see.
- What I will build.
- How it's accepted.
- The hard criteria for moving to the next stage.
Then I tell you: none of this blocks me, but here's what I need from you, and by when.
What you experience
One big risk becomes small stages. I drive the work, not the other way around. You watch the nodes complete and the problems surface and get closed, one by one. Nothing to chase, nothing to manage. Just a drumbeat of stages completing on schedule.
Why I work like this: attention economics
I'm a full-time independent. My scarcest resource is attention. Whoever saves my attention, I pay real money for, and I repay clients the same way: lowest communication overhead, highest information density. That's why async plus email is my main mode. Proactivity on top of agreed outcomes is the mode I enjoy — and it's genuinely fast.
A spec is one way to de-risk a project. A drumbeat of kept promises is another, and it works when no spec exists yet.
This is how I actually run contracts, written from practice rather than theory. No specific client, machine or project is described.
Companion note, same vein: Why I lead with a runnable demo.
If a machine you build needs an interface, a device connection, or data that has to land somewhere else, tell me what it's costing you now. You'll get an honest read on whether it's solvable, and usually something running to look at. Start here →