Approach
Before anything is built
Technology follows the decision — not the other way around. The work begins by finding the real problem and the weakness behind the request.
Most projects arrive with a preferred answer already attached: a platform, a dashboard, a model, a mobile app. The conversation starts at “how do we build it?” when it should start at “what has to change in the operation?”
See the weakness
Every request hides a weakness — evidence that does not exist, a decision made too late, a process that cannot absorb exceptions, a site that cannot be seen from the centre. Name that weakness clearly and half the proposed architecture falls away.
Say what not to do
Judgment is incomplete without refusal. What will not move the needle. What to stop. What looks strategic and is only theatre. Saying no early is cheaper than shipping a system nobody will run.
Build only what the case needs
Sometimes the right answer is something we already run. Sometimes it needs to be built. Sometimes the right answer is not to build anything at all. Ownership means staying for the outcome after it ships — measured value, not only delivered artefacts.
That is the Eeklin sequence: See → Say → Build → Stay. Before anything is built, we decide what is worth building.