Software projects rarely fail in the code. They fail earlier, in the gap between what the client said they needed and what the work actually is. By the time that gap shows up, everyone has already spent the money.
This post is about how we close that gap before quoting, and why we do not charge for it.
The 220kV problem
Some years ago I was asked to build a virtual-reality training system for 220kV high-voltage substations. It was a domain I did not know. I had built VR before; I had never worked in power transmission.
The briefing document described the training scenarios in perfectly reasonable language. Isolation procedures. Switching sequences. Personal protective equipment. Emergency response. Anyone could have read it and produced a quote in an afternoon.
I did not have enough to build from, so I went to look.
Over the following weeks I visited operating stations, control rooms and equipment suppliers across the network. I watched the switching procedures performed. I asked what trainees actually get wrong, and what a supervisor watches for when a new operator approaches live equipment. I asked the suppliers what the hardware really looks like, and where the models we would need would come from.
None of that was in the briefing document, and none of it could have been. It is not the kind of knowledge an organisation writes down, because everyone who works there already has it.
Only after that did I write the proposal. The contract was signed against a scope that reflected the work rather than the description of the work, and the project was delivered.
I am not certain it would have survived being quoted from the document alone.
What the visits are actually for
The purpose is not to gather requirements in the clerical sense. It is to find the things that would have broken the project, while breaking them is still free.
There are usually three:
The work is not what the process says it is. Every organisation has a documented process and an actual one. The actual one contains the workarounds people invented when the documented one met reality. Software built to the documented process gets rejected by the people who have to use it, and they are right to reject it.
The hard part is not where you think. In the substation project, the hard part was not the physics or the rendering. It was that a trainee must be allowed to make a fatal mistake, feel the consequence, and understand why — without the system telling them the answer in advance. That is a design problem, and it changes what you build. Nobody says this in a briefing. You find it by watching an instructor teach.
Somebody else's system is in the way. There is nearly always a dependency the client has stopped noticing: a supplier's data format, a legacy machine nobody can turn off, an approval that takes three weeks. Discovered at the start, it is a design constraint. Discovered mid-build, it is a variation, an argument, and a delay.
Why this is not charged for
Most firms charge for discovery, and they are not wrong to. It is real work, it takes real time, and free work is often work done badly.
We do it without charge for two reasons, neither of them generosity.
The first is that we have no sales apparatus to fund. There is no business development team, no bid office, no proposal department. The week that another firm spends producing a document about itself, we spend on your operation instead. The cost is roughly the same. The difference is where it goes.
The second is that we would rather find out early. A project that should not have been taken on is expensive in ways an unpaid week is not — it is expensive for a year, and it is expensive in what people say afterwards. Discovery is where both sides find that out. Occasionally the answer is that the client does not need custom software at all, and we say so.
To be exact about it: our time is free. Travel and any third-party costs are agreed in advance, because those are not ours to absorb and pretending otherwise would just move them into the build price.
What you get at the end
A written assessment: what we think should happen, the realistic options, and what each would cost to build and to run. It is yours whether or not you continue, and it is written so that another firm could implement it. That is deliberate. A document you can only use by hiring us is a sales tool, not an assessment.
If it goes ahead, the same understanding becomes the basis for agreeing what "finished" means — enough detail to price the work honestly, not so much that it cannot change when reality arrives.
The general case
Not every project needs weeks of site visits. A booking system for a six-person business does not warrant what a substation training simulator warranted. The principle scales down, but it does not disappear: look at the actual work before you commit to a number.
The unpaid days at the start are the cheapest days in the whole project. Everything you learn later costs more.