We build a prototype your people use on real work, and change it until it fits.
The main risk is answered. The open question is what this should be like to use. Your team uses a working build on live work and we change it every cycle, until the shape settles.
Why the shape cannot be settled in a meeting.
Where does it sit in the workflow? What does it ask of an associate in the middle of a matter? Several people hold strong opinions, and none of them can be tested on a slide.
A prototype is built to be replaced, so being wrong is cheap. Most of its value is in what it kills: the feature nobody used and the workflow that looked right on paper.
How it works
We build the shape, not the product
The scope, the look and the function, without the engineering that makes software last.
Your people use it on real work
Named users in the team and in operations, on their own matters.
We change it every cycle
The workflow, the interaction, the outputs. Each cycle answers what the last one found.
We stop when the shape settles
Then we write down what worked, what to keep and what to drop.
What you get
Testable software
A working build your own people use, changed every cycle.
Iteration cycles
Each cycle runs with the same named users.
Change notes
What changed between cycles and why.
A shape brief
What to keep and what to drop, for the production build.
Frequently asked questions
Why not build it properly the first time?
Because the first version is rarely the right shape, and changing a prototype costs far less than changing production software. The production build comes after, scoped against a shape your people have used.
Couldn't our own team build the prototype?
If they have the time, yes. Internal builds tend to stay, whether the shape is right or not. Ours is built to be replaced, and it ends in a written note on what to keep.
Doesn't our vendor's product already do this?
Try it. If it fits your workflow, you are done. A prototype is for the workflow that is yours and not the market's.
Can clients see it?
No. It stays internal and temporary. Nobody maintains it, and nothing it produces goes to a client.
How long does a Prototype take?
Often one to three months. It depends on the scope and on how quickly the shape settles with your people. We agree the cycles before we start.
What comes after?
A Minimum Viable Product: the same shape, built to be maintained, in front of a first group of real users. If the main risk is still open, a Proof of Concept comes first.
More in this track
See the shape before you commit to it.
Tell us what has been tested so far and who would use it every day. If a risk still needs answering before anything is built, you hear that before we scope a prototype.