Why context comes before code

Software rarely fails on the code. It fails because the wrong thing got built — flawlessly, just not the thing the business needed. That is why a project here does not start with writing code. It starts with understanding the context.

It sounds like a platitude until you see how much money it wastes. A team ships exactly what the brief asked for. The brief was wrong. Nobody is at fault and everybody lost months.

Why the wrong thing gets built

A client knows what hurts. They do not always know what is causing it — and they almost never know how to phrase it in the language of software. That is fine. It is not their job.

The trouble starts when a vendor takes it literally. "We want a button that sends a report." We build the button. A month later it turns out nobody reads the report, because the real problem was that the numbers do not match between two systems. The button was built correctly and was completely pointless.

Context is exactly what the brief does not say, because to the client it is obvious: how the process actually runs, who uses it, what happens when it breaks, why they do it this way today.

What gathering context looks like in practice

It is not a workshop full of sticky notes. It is a series of questions that ask "why", not "what". Why does it take three days? Why do two people approve it? What broke last time and how did you handle it?

The answers often surface something that changes the brief entirely. Suddenly it is clear that no new system is needed — connecting two existing ones is enough. Or the opposite: the thing that sounded like a detail turns out to be the whole problem.

For more on how that gathering runs and what comes out of it, see what happens in a first consultation.

Why this is cheaper, not more expensive

The first reaction is that "talking" before development is a delay. The opposite is true, and you can do the arithmetic.

Changing the brief on paper costs an hour. Changing a finished system costs weeks — you rewrite the code, the tests, the documentation and often the data too. The later a misunderstanding is found, the more it costs to fix. A day spent understanding the context saves a month of rework.

The same holds for AI projects, where the temptation to "try it and see" is strongest. On when not to deploy AI at all, see where not to use AI.

The takeaway

When you pick a vendor, watch whether they ask first or propose a solution immediately. Anyone who knows exactly what to build at the first meeting either got lucky or was not listening. We call the approach Context Driven Development, and it is the basis of how we work.

If you have a project where you are not sure whether you are addressing the cause or the symptom, get in touch — the first consultation is free, and people often leave it with a different view of the problem.