Three weeks of honest diagnosis save three months of building toward the wrong target. Here's how we work out what's actually going on with you - before the first line of code gets written.
Most software projects don't fail in the building. They fail much earlier - at the question of what should be built in the first place.
Whoever starts with the wrong understanding of the problem builds the wrong solution - no matter how skilled the craft. That's exactly why our work doesn't begin with a spec sheet, not with mock-ups, not with sprint plans. It begins with questions you've probably never been asked quite like this - and with answers that will often surprise you.
We ask
Vision, pain points, daily life, limits - in the right order.
You show
Screenshots, lists, examples - what words can't show.
We design
Three tiered paths with price, scope and time. You choose.
When a client comes with the request "We want a CRM," that's not a problem description. It's a solution hypothesis. The real question lies beneath: Where do customer contacts get lost today? Which enquiry was never answered? Who didn't know what? We take wishes seriously, but we don't take them literally.
Spec sheets aren't wrong - they're just the result of the wrong first question. Whoever asks "What should it do?" gets a list of functions. Whoever asks "What goes wrong today?" gets problems described. From functions we build software no one needs. From problems we build software someone misses when it's gone. That's not the same thing.
The classic essay is "Marketing Myopia" by Theodore Levitt (Harvard Business Review, 1960). Levitt's thesis: railway companies didn't go under because demand for transport fell - they went under because they believed they were in the railway business instead of the transport business. They confused the product with the problem.
Clayton Christensen sharpened this in "Jobs to be Done": no one buys a drill because they want a drill - they want a hole. Software projects get lost for exactly the same reason: the client describes the drill they have in mind. The consultant's job is to find the hole they actually need.
For years, you've been copying customer data from your inbox into an Excel list, from there into the accounting program, from there back into your email tool. In the interview, you don't mention it - it's normal. Routine becomes invisible the longer it lasts. It's there like the wallpaper in the living room: you only notice it when someone asks.
That's exactly why we don't just ask questions - we ask follow-ups. When you say "an order takes about an hour with us," we ask what specifically happens in that hour. When you say "we have a tool for that," we ask how often the tool is really used, and who notes what outside it. That's how the steps surface that aren't in any manual - but cost time every day.
The psychological finding is old and well-established. Nisbett & Wilson showed in a much-cited 1977 essay ("Telling More Than We Can Know", Psychological Review): people often don't know why they do something - and when they explain it, they invent plausible reasons that have little to do with their actual behaviour. That holds for consumer decisions just as much as for work routines.
The sociologist Donald Schön described the same phenomenon as "tacit knowledge": knowledge we have in the doing, but can't access in the talking. Experienced practitioners can often explain what they do, but not why it works. Whoever builds software for that practice has to surface the implicit knowledge as well - not just the explicit.
Feature wishes are speculation. The status quo is reality. Whoever asks about functions first invites the client to imagine solutions they can't evaluate. Whoever asks about the daily routine first comes back with concrete material - real bottlenecks, real decisions, real mistakes. Solutions can be derived from that material. Not from invented features.
That's why our best questions sound almost trivial: Describe a typical Tuesday for me. Who sends you the first order of the morning, and in what form? What do you do next? The last time something got lost - how did that happen? Which action do you type more than ten times a week? These questions sound like small observations. But out of twenty of them, a precise picture emerges of what really needs to be built.
In the Toyota Production System it's called "Gemba" - the "real place." Taiichi Ohno, one of the system's architects, made a rule of it: Go to where the work happens. Watch. Ask there, not in the conference room. Whoever doesn't know the actual workplace can't improve it - regardless of how good the theory is.
This was rigorously worked through academically by Wil van der Aalst (TU Eindhoven) under the term process mining: the discipline of reconstructing actual processes from real data - not the ones described in the manual. Studies regularly show deviations of 30 to 60 percent between the expected and the actual process landscape. Whoever builds for the expected version builds for a world that doesn't exist.
What people say about their work almost always differs from what they actually do. Not from dishonesty - but because memory smooths what's bumpy in everyday life. That's why we don't just ask you to answer questions. We ask you to upload evidence: a screenshot of your most important tool. A photo of the note on your desk. The Excel file you actually type into. An example of a quote you wrote last week.
These artefacts don't lie. They show the date no one says out loud. The column not mentioned in the interview. The handwritten note in the margin that betrays where the digital process ends and real life begins. An hour of gathering material is often worth more than three hours of phone calls - because with it we see what you no longer see.
In economics, this distinction is known as "stated vs. revealed preferences" - introduced by Paul Samuelson in 1938 (Economica). What people say they would prefer and what they actually do are two different datasets. Market research over the last 80 years has confirmed the finding countless times: behaviour is more reliable than self-report.
In UX research, this turned into a maxim: "Watch what they do, not what they say." Jakob Nielsen, one of the field's pioneers, put it this way: "Self-reported claims are unreliable, as are user speculations about future behaviour." Our consequence: we don't ask only for words. We ask for the things you work with today.
If we ask about budget too early, the answer cuts off the solution space before the first thought. Someone who says "We have 8,000 Euro" spends the next two hours making plans for 8,000 Euro - regardless of whether the problem is actually larger or smaller. We reverse the order: first the vision, then the pain, then the solution - and only at the very end the question of what you're willing to put toward it.
This isn't naive. We know budgets are finite. But the budget determines the order of implementation, not the value of the problem. Whoever starts with budget loses the hierarchy. Whoever starts with value and brings the budget in at the end gets an honest list: this is the effect, here is the price, and that's how they fit together.
Tversky & Kahneman described the anchoring effect in their 1974 Science essay "Judgment under Uncertainty": the first number named in a discussion distorts all subsequent evaluations - even when it's obviously irrelevant. The effect has been replicated hundreds of times in negotiation and sales settings. Whoever talks about money first has already lost the discussion about value.
In sales, the corrected order is described in Neil Rackham's classic "SPIN Selling" (1988): first situation, then problem, then implication - what does the problem cost you today? - and only at the end, the solution with its price. Studies on B2B sales conclusions show: this order leads to significantly higher contract values and at the same time to more satisfied customers. We don't use the logic in sales - but in diagnosis. The goal is the same: understand first, place second.
We don't give you one recommendation. We give you three. Small - what solves the most painful point first, doable in weeks instead of months. Medium - the core of what we can manage in a quarter, with clear effect in the daily routine. Large - what truly reaches the vision from the first conversation, with everything that goes with it.
Each path comes with scope, price and timeframe. We mark which one we would recommend from experience - but the choice is yours. This isn't us taking the easy way out. It's the most honest form of consulting: we can tell you what we would do in your place. But we're not in your place - you know the pressure, the politics, the mood in your house better than we do. Three paths give you the leverage to make the right decision yourself.
The psychological foundation is the Asymmetric Dominance Effect (Huber, Payne, Puto, 1982): when people face two options, the decision is hard. As soon as a third option enters that structures the field, they choose much more decisively - and are more satisfied with the choice. Three options are the cognitively most favourable number: one is dictatorial, two force black-and-white thinking, four overwhelm.
Related is the choice architecture research of Cass Sunstein and Richard Thaler ("Nudge", 2008): whoever presents decisions in a structured way helps without patronising. Three tiered paths are exactly that. They don't take the choice from you. They make it manageable.
Care in understanding, courage to cut. Whoever has one without the other doesn't get far.
These six steps aren't consultant choreography. They are the only approach we know that, before building, honestly clarifies whether the right thing should be built at all. Three weeks of diagnosis aren't proof of thoroughness - they are the price for not wasting the next three months. And at the end there are no slides, no workshops, no certificates - just three concrete paths you can decide between. That's all you really need at this stage.
More on how we proceed after the problem analysis is on Tools first, AI second. Which hurdles most often appear during rollout in businesses, you'll find on The biggest hurdles rarely lie in the technology. An honest take on the risks of AI is on What AI can't do, even when it looks like it can. Our quality standard for good software is summarised on When is software actually good.