RABBIT HOLE3 MIN
Explore → Understand → Build
The loop I keep running, and why the middle step is the one everybody skips.
Every interesting thing I have built started the same way: I saw something, did not understand it, and refused to leave it alone.
That is the whole method. Three steps, run in order, repeatedly.
Explore
Go where the information actually is.
For software, that is documentation, source code, and the issue tracker where somebody has already hit your problem and given up. For hardware and physical products, it is showrooms, exhibitions, factories, and people who make things for a living. For a market, it is customers who are currently solving the problem badly with a spreadsheet.
What matters is that exploration has to be physical often enough to stay honest. Catalogues and landing pages describe products the way they were meant to be. The interesting details — what breaks, what is actually in stock, what the real minimum order is, what everyone quietly works around — do not make it into the PDF.
Understand
This is the step everybody skips, and it is the one that pays.
Understanding is not “I read the spec sheet.” It is being able to explain why a thing is built the way it is, what it costs, what it cannot do, and what would have to change for that to be different.
A worked example, without naming anyone: two products can look identical in a listing and differ by 4x in price. The gap is never mysterious. It is a component, a tolerance, a certification, a volume commitment, or somebody’s margin. If you cannot name which one, you do not understand the product yet — and you are about to make a purchasing decision on vibes.
The uncomfortable version of this rule: if you cannot explain why the cheap one is cheap, you are the reason it sells.
Build
Only now.
Building before understanding produces something that works in the demo and dies on contact with a real user, a real warehouse, or a real supplier lead time. I have shipped that thing. More than once.
Building after understanding is boring in the best way. You already know where the hard parts are, because you went and looked.
Where the value hides: arbitrage
Here is the pattern worth naming.
Technology has wildly different value depending on where it lands. A component that is unremarkable in one market — mature, commoditised, boring, competing on price — can be genuinely useful somewhere it has not arrived yet. Not because anyone is behind, but because the problem it solves has not been connected to the thing that solves it.
That gap is technology arbitrage: finding useful technology somewhere and figuring out where it actually creates value somewhere else.
It is not clever. It requires no invention. It requires being in two places, understanding both, and noticing.
The catch is that it only works after the middle step. Arbitrage without understanding is just importing things and hoping. Plenty of people are doing that, and their warehouses are full.
The loop
Explore → Understand → Build → and then, because building always exposes what you missed, Explore again.
That is it. It is not a strategy. It is closer to a personality trait that I have decided to be organised about.
Most of what appears on this site will be some point in that loop, written down before I forget the details.
- technology
- strategy
- arbitrage
- method
Related notes
BUSINESS3 MIN
Two Operating Modes
What actually changes in an engineer's head when the problem stops being technical and starts being a business.
BUILD LOG2 MIN
Build things. Explore ideas. Chase snow. Repeat.
Why this site exists, and the four modes I seem to cycle through whether I plan to or not.