Almost every serious project we take on starts with a paid two-week diagnostic. Clients reasonably ask: why should I pay before you've built a single screen? The answer is that those two weeks are the cheapest part of the whole project — and the part that decides whether the rest makes any sense. This is the exact breakdown of what happens in them, what you get at the end, and the number on the invoice.
The diagnostic is the front door to our IT consulting service. It isn't a sales call wrapped in an invoice. It's real work by two senior people that ends in a document you could take to a different supplier if you chose to.
What happens in week one
Week one is about what already exists and what the client actually wants — which aren't the same thing as often as you'd expect.
- A kick-off on day one, 90 minutes, where we write down what we'll treat as project success and the window we'll measure it in. Without that sentence the diagnostic dissolves into impressions.
- Three to five stakeholder interviews — not just whoever signs, but the people who'll actually use the thing. The director and the bookkeeper often want contradictory things from the same tool.
- An audit of what's running, if a system exists: codebase, infrastructure, AWS/GCP bill, integrations. On a greenfield project we map the processes the software will replace instead.
- Process maps for both sides of the transaction. There's always a step nobody mentioned out loud because 'everyone knows that one'.
What happens in week two
Week two is about whether it can be built sensibly — and for how much. This is where we stop listening and start drawing.
- An eval framework: concrete, measurable criteria by which, three months from now, we'll say whether the MVP works. Not 'users like it' but 'a booking takes under 60 seconds in 90% of cases'.
- A risk map: what could sink us — legislation, a third-party integration with no real API, data someone promised that doesn't exist. Every risk gets a colour and a sentence on what we'll do about it.
- An architecture sketch at the level needed for an estimate, not an implementation. Stack, main components, where the data lives, where the boundaries are.
- A scope-and-cost estimate as a range, not a single number. A single number is always a lie; a range with an explanation of what moves it up and down is the truth.
What we deliver at the end
The output isn't an hour-long presentation that leaves you with a logo'd PDF. It's a document that still makes sense six months later, when a new person on the team opens it.
- A fifteen-to-twenty page memo: context, goals, eval framework, architecture, risks, estimate. We write it so a non-technical founder and the engineer who'll build it can both follow it.
- A one-page summary on top — for whoever signs and hasn't got time for twenty pages. The recommendation is explicit: build, don't build, or build differently.
- An architecture diagram that isn't a marketing picture but something you could actually start from.
- A risk register with owners and statuses that carries straight into the project if we go ahead.
What it costs
Two senior people, roughly ten working days. The diagnostic runs between €6,000 and €9,000 depending on how much existing infrastructure there is to audit. It's a fixed line item agreed up front — not an hourly rate that balloons along the way. If we go ahead with the project, we credit that amount against the first development invoice.
The most expensive thing in software isn't bad code. It's six months building the right thing for the wrong problem. Two weeks is the cheap insurance against that.
The projects we turn down after a diagnostic
Roughly one in five projects, after the diagnostic, we don't recommend building — or at least not the way the client arrived wanting to. Sometimes the problem is solved by an off-the-shelf tool at €40 a month and custom software would be waste. Sometimes it isn't clear who will use the product, and then we'd rather hand back another round of questions than code. We put that refusal in writing — the same way that, before we quote a network, we put in writing what we won't wire in before we sign. If you want a second opinion on your project before you pour six months into it, get in touch — that's exactly what the diagnostic is for.