Prototype instead of specification: why small steps make IT projects cheaper
5 min read
Short answer
A working prototype after a few weeks shows faster and more cheaply than an extensive specification whether a solution works in daily practice. Your team tests with real data, misunderstandings surface early, and you decide based on results. A detailed specification still makes sense when tenders, liability questions or many parties require it.
What does this mean for your company? Book an intro call
Many IT projects in small and mid-sized companies begin with a thick document. Months pass until all requirements are written down and agreed. When the first version is finally ready, it turns out that much was understood differently from how it was meant. There is a faster and cheaper way.
What is the problem with long specifications?
People find it hard to picture software from text. A sentence such as “the application shows all open cases” sounds clear, until someone asks what “open” means exactly. Such ambiguities only surface when someone works with the application. The later that happens, the more expensive the change.
On top of that, the business keeps changing while the specification is written. Requirements written down in spring no longer quite fit in autumn.
How does a prototype project work?
- Define goal and scope: one process, one measurable goal, a fixed timeframe and a fixed budget.
- Build: within two to four weeks, a working version is created that works with real data.
- Test: the people who will use the solution work with it and give feedback.
- Decide: expand, change or stop, based on what happened in the test.
In my projects, a first working version for a clearly defined process is frequently ready after about two weeks. This version is not a throwaway model, but the foundation of the finished application.
Why is this cheaper?
Because errors surface early. A wrong assumption that becomes visible after two weeks costs a day of correction. The same assumption after six months of development costs weeks. In addition, only what is really needed gets built. Features included in a specification “just in case” often turn out to be unnecessary when working with the prototype.
When do you still need a specification?
- For public tenders or funded projects with fixed requirements
- For large fixed-price projects with several suppliers
- In regulated environments where requirements must be documented verifiably
Even then, a prototype helps beforehand: it settles the key questions before they are fixed in the specification.
What should you look for in offers?
- Fixed scope and fixed price for the prototype
- A clear success criterion on which the decision is made at the end
- Rights to the source code and your data
- No long commitment before the prototype has convinced you
Why many AI pilots still stall, and how to prevent it, is covered in Why AI pilot projects stall.
Julius Launhardt steers IT projects in small and mid-sized companies in small, verifiable steps, from prototype to operation. More on the IT project management page.
Frequently asked questions
Is a prototype not wasted money if it is thrown away?
A properly built prototype is the foundation of the finished solution and is developed further. And if it turns out the idea does not hold up, that was the cheapest possible lesson.
How long does a prototype take?
For a clearly defined process, often two to four weeks. In my projects, a first working version for a single process is frequently ready after about two weeks.
Do I no longer need any requirements?
You do, but in compact form. Goal, scope, success criterion and the key constraints fit on a few pages. The details emerge together on the running system.
Who owns the source code of the prototype?
That should be settled in writing before the start. I recommend that you receive the rights to the code and your data, so you do not depend on a single supplier.