This conversation repeats itself with enviable regularity. A client comes with an idea, we discuss the task, and I suggest starting with design: analysis, architecture, a technical specification. The client frowns: "Wait, why should I pay for a document? I want a system, not paperwork. Let me write down what I need myself, and You just estimate it and build it." A week later he brings three pages of text containing wishes, examples of competitors, the phrase "like Excel, only more convenient" and the obligatory "intuitive interface". I truly value that document, honestly. But it is not a technical specification. It is a letter to Santa Claus.
A specification is not a wish list, it is a blueprint
Let us compare it with something everyone understands. You have decided to build a house. You can go to a construction crew and say: "I want two floors, bright, with a big kitchen, and it should feel cozy." The crew will certainly build something. But where the load-bearing walls go, what foundation this soil needs, how the sewage will run, whether the floors can hold a bathtub on the second level, the foreman will decide on the fly. And then it turns out there is no riser for the second bathroom, and to add one You have to break through a finished wall.
That is why in construction nobody has argued for a long time that an architect's design comes first and is paid for separately. In software development, for some reason, people still argue about it. Yet a software system is in no way simpler than a house: it also has a foundation in the form of a data model, load-bearing walls in the form of architecture, utilities in the form of integrations, and finishing in the form of the interface. And a mistake in the foundation discovered at the finishing stage costs dozens of times more than if it had been found on paper.
A technical specification is the cheapest moment to make a mistake. After that, mistakes only get more expensive.
Why a self-written specification is dangerous
I am not saying a client is incapable of writing a good specification. Sometimes they are, especially if they have experience and an analyst on staff. But in most cases a self-written specification suffers from the same diseases, and the problem is not the author's intelligence but their position.
The first disease: the client does not know the technical constraints. They do not know that the small phrase "and everything should sync in real time" turns a simple project into a complex one and doubles the budget. They do not know that the payment service they picked lacks the needed feature. It is not their profession, and it should not have to be.
The second disease: a solution is described instead of a problem. "We need a button that exports a report to Excel" instead of "the accountant has to reconcile payments with shipments every month". The first can be done, but perhaps the second is solved in a completely different way, with no Excel at all.
The third disease: the most boring parts are missing. Access rights, error handling, what happens when an order is cancelled, who corrects wrongly entered data and how, what happens if two managers edit the same client at once. This is exactly where projects break, and these points never appear in a letter to Santa Claus.
The outcome is predictable. Developers who receive such a specification do one of two things. Either they add a huge buffer for the unknown and overestimate the project, and the client leaves for whoever named a smaller number. Or they honestly build exactly what is written, and three months later there is a system that formally matches the document and still does not solve the problem. Then the arguments about who is to blame begin, and spoiler: usually everyone loses those arguments.
Why design is a separate paid stage
A good specification is the result of work. An analyst examines the company's processes, talks to the people who will use the system, and finds contradictions between what the director says and what employees actually do. An architect decides how the system will be built, which technologies are needed and where the risks are. That is weeks of qualified work, and it can be free in only one case: if its cost is secretly hidden in the development price. Then You still pay for it, You just do not see how much and for what.
A separate design stage has one more huge advantage that people rarely mention: it makes You free. Once You have a paid specification, You own it. You can take it to any contractor, compare offers based on the same document rather than on different fantasies, and choose the best one. Without a specification each contractor estimates their own version of Your project, and comparing those estimates is as pointless as comparing prices for "some kind of car".
What the client should do
My advice is not to write nothing Yourself. On the contrary: write down everything You know. Describe how Your business works today, where it hurts, which processes eat up the most time, who will use the system and what You expect a year from now. Collect samples of documents, spreadsheets, reports, screenshots of what You use now. This is priceless material that will save the analyst weeks. But turning that material into a technical specification should be the job of someone who knows how to build systems.
And one more thing: treat design as insurance. A small share of the budget spent at the paper stage protects the main part from rework. At Systems we always start with this stage and hand the result to the client as a standalone document they are free to do anything with. And Fractal lets us turn a system description into a working prototype very quickly, so our specification does not lie around as dead paper but almost immediately becomes a screen You can touch. But everything starts with a blueprint. People build a house without a blueprint only once; nobody wants to do it a second time.
