The most expensive line of code is the one written for a problem nobody understood. It compiles, it passes review, it ships. A few weeks later someone notices it answers the wrong question, and undoing it costs more than writing it did.
That is why we try to understand the work before we write any of it. Clients sometimes expect momentum to mean commits. In our experience, momentum means never having to go back.
The same screen, two different products
A booking form for a tyre workshop and a reservation button for a café look almost identical in a wireframe. In practice they are different products. A tyre customer is often at the roadside, on a phone, with a flat. They want a quick answer more than a calendar. A café guest is planning an evening and wants to see the room first.
When we built the sites for Gomisteri Kasmi and Caffè de Paris, that difference decided what came first on the screen. It is also why WhatsApp sits one tap away on both: it is how their customers already talk to them.
None of that appears in a feature list. It only shows up when you ask.
We find differences like these with a fixed set of questions, and the answers end up on a one-page architecture note. Both are described, with a worked example, in How we scope a project in one week. The rest of this article is about what that understanding does to the software itself.
Example: mapping Test-Start's exam flow
Test-Start is a practice platform for the driving theory exam in North Macedonia. Candidates take timed mock exams of 30 questions in 60 minutes, for categories B and C/C1, in Albanian or Macedonian.
On the surface it is a quiz app. Before building it, we mapped the exam the way a candidate actually experiences it, and the model had more structure than a quiz:
Category B | C/C1
Test numbered set | random set
Attempt 30 questions · 60-minute timer
Format multiple choice | road sign | matching
Language Albanian | Macedonian
Result per question, then a total scoreEach line of that diagram raised a question we answered in week one rather than week six.
Categories. Is a category a filter on one shared pool, or its own exam? Treating it as its own exam definition, rather than a tag, keeps the rules for B and C/C1 from leaking into each other.
Timing. Where does the clock live? A timer that exists only on the page is easy to reset by accident. Thinking of each attempt as something with a start and an end keeps the time limit honest.
Scoring. Three question formats means three ways of checking an answer: one correct option, a sign identified, a set of pairs matched. Each needs its own checking rule, written and tested once.
Languages. A question and its translations are one item with two texts, not two unrelated records. Why that matters is in Multilingual is a data problem.
Understanding also defines the end
The same understanding decides what "done" means, and it is written into the contract in the same terms: the agreed journeys work in production, on the devices and in the languages named at the start. Ownership and documentation are part of done too; what they mean technically is in The handover is part of the product.
Understanding pays for itself
Time spent understanding the work produces little to show and a lot to rely on. When the code starts, we know who it is for, what it replaces, what it must protect and what finished looks like.
The rest of the project is execution, and execution is the part that is easy to estimate.
What this means for your project
Before any code, find out how the work really happens and what must never break. Two products that look the same in a wireframe can need different data models, and that is far cheaper to learn on a whiteboard than in production.
