How we work
Why we build a clickable prototype before writing any code
We build a clickable prototype before writing production code because it is the cheapest point at which to be wrong. Moving a button in a prototype takes minutes. Moving it after the feature is built, tested and connected to a database takes days, and somebody has to pay for those days.
What a prototype actually is
Clickable screens of the main flows — not a document, not a wireframe sketch. You can open it, click through the journey your users will take, and discover that step four makes no sense before anyone has built step four.
It is deliberately not working software. There is no database behind it and no logic. That is the point: nothing in it is expensive to throw away.
What it changes about the price
We fix the scope and the price once the prototype is agreed, not before. Quoting a fixed price on a paragraph of description means one of two things: the number is padded to cover the unknowns, or it is honest today and gets revised upward later.
Pricing against screens everyone has already looked at removes most of that guesswork, which is why our fixed price comes after the prototype rather than before it.
The questions it answers early
- Is this the flow your users will actually follow, or the one that made sense in a meeting?
- Which screens turned out to be unnecessary once you clicked through them?
- What did nobody mention until they saw it on screen?
- Is the scope bigger than the budget — while that is still a conversation, not a problem?
Every one of those is cheap to answer now and expensive to answer in month three.