Spec Phase
The spec phase is the part of a project where it is precisely written down what is to be built – before anyone starts building it. The result is a document against which everyone involved will later be measured.
Before a team builds a piece of software or a device, it must be clear exactly what is supposed to be created. This is precisely what the spec phase is for. “Spec” is the short form of the English word “specification”, meaning specification or description. In this phase, the team writes down what functions the product must have, how it should behave, and how one can ultimately tell that it is finished. Only afterward does the actual work on the product begin. You can think of it like an architect’s blueprint: it is drawn before the first stone is laid.
The Price of a Forgotten Sentence
Errors in a project become more expensive the later they are noticed. A missing sentence in the description costs five minutes. The same mistake, discovered after six months of programming work, may cost months. That is why the spec phase is considered the cheapest place in a project to argue.
The second reason is mutual understanding. People with very different perspectives work together in a project: developers, designers, sales, and often lawyers too. Everyone uses the same words but means different things. When someone says “the system should respond quickly”, one person thinks of a second, another of a minute. A specification forces such sentences to be translated into numbers.
Third, the specification serves as a benchmark. Without it, you cannot say whether a product is finished or not. With it, you can check things off point by point. In contracts between companies, the document is even part of the contract.
From Wish to Testable Statement
At the beginning, there are conversations with those who will later use or pay for the product. From these conversations, a list of requirements emerges. Each requirement is reworded so that it can be verified. For example, “the app should be user-friendly” becomes: “A new user completes registration in under three minutes.” Such statements are called acceptance criteria.
It is important to separate the What from the How. The specification describes what should happen. How it is technically solved is decided later by the development team. Anyone who mixes the two takes away the freedom to find better solutions.
Finally, everyone involved reviews the document and signs off on it. However, it is not set in stone after that. Changes are allowed, but they go through a fixed procedure so that no one is caught by surprise. A common misconception is that the spec phase must clarify every little detail in advance. In practice, a concise document that cleanly captures the risky points and leaves the rest open is often enough.
Specs in AI Products and in Tech Press
In news about tech companies, the term appears when a project is delayed. Sentences like “the product is still in the spec phase” mean: it is not yet being built, it is still being described. For investors, this is a signal that a lot of time will pass before launch.
AI systems are also specified, though differently. A language model cannot be defined line by line because it learns from examples rather than working strictly by rules. Companies therefore write down behavioral rules: which questions the model may answer, which it may not, and what tone it should strike. OpenAI has published such a document under the name “Model Spec”.
A related term is the statement of requirements (Lastenheft): in it, the client writes down what they want, while the functional specification (Pflichtenheft) is the contractor’s response. Anyone who programs themselves encounters this principle on a small scale. Before handing off code to an AI assistant or to classmates, it helps to write down in three sentences what the outcome should be.
