A conversation before the first line of code

Regular conversations don’t start with a problem, but with an answer. “We want an app for our mechanics.” “We want a dashboard where everyone has insight.” “Can you connect this system to that system.” The solution is already there before we even know what goes wrong. That’s the starting point of almost every project with us, and it’s exactly the point where we don’t start building, but ask questions.

The solution comes before the problem

Someone who calls has usually thought about it. He’s seen how another company did something, or a colleague has followed a demo somewhere, or he’s been looking for what other companies are using himself for a while. By the time he calls us, he already has a name for what he wants: an app, a portal, a link. That’s not crazy. Anyone who experiences a problem is looking for something that solves it, and the first thing you find is usually the most concrete: a piece of software with a name on it.

The point is that this solution has been devised without anyone figuring out exactly where it really goes wrong. An app for mechanics doesn’t solve anything if the problem is that no one knows what information should end up in the office. A dashboard doesn’t make sense if the figures in it aren’t reliable yet. A link between two systems doesn’t work like in both systems other definitions of the same customer.

Why that happens so often

This isn’t because entrepreneurs think badly. It’s because you’re too close to the problem within your own company to see exactly where it comes from. A process developed years ago as a practical solution to something small: an Excel file to keep orders, an email as approval, a phone call as a matter of urgency. That worked, until the company grew and more people, more customers and more exceptions were added. At some point, you only notice the symptoms: double work, errors, a colleague who has everything in her head. The cause is deeper, and you only see them when someone looks outside.

The conversation we’re having

Before we build something, we first spend an hour with the entrepreneur to map the current process. Not the wishes, the process as it is actually going on. Who does what, in what order, with which file or system, and what happens when someone is sick or a customer asks something unusual. We ask about the moments when things go wrong: where do the mistakes occur, who notices them first, and how much time does it take to fix them.

The answer to that call often differs from the one someone called. Sometimes it turns out that there is no need for a new application at all and that Replace the existing Excel file Because of a well-designed structure, it seems that sometimes the demand was too small: not a single link, but a complete customer portal in which customers can see their own status, ultimately saves more calls than the one link that was asked. And sometimes the conclusion is that nothing needs to be built, because someone has to be internally responsible for the data that comes in. We deliver that conclusion just as easily as a proposal to start.

What it delivers, and where its limits are

The result of that first conversation is a sharper question. Not “build an app,” but for example “make sure that a mechanic can see on site which parts are in stock, and that that stock automatically updates”. That’s a question that you can make a good price and a good planning, and that you know in advance if he actually hits the problem. Without that conversation, you build something that fits the wish on paper, but that after delivery simply allows the underlying problem to exist.

There is also a limit to what this conversation solves. Software solves a process, not an organization. If no one wants to bear the responsibility to keep data up to date, or if two departments disagree structurally on who the customer “possess,” then a new system doesn’t change that. Sometimes we only notice that after a few questions, and then we say so. approach That’s why always starts with that conversation, not with a quote.

It may be the least exciting part of a project: talking for an hour before something is built, but it saves most time afterwards, and it prevents you from paying for something that doesn’t touch your problem.