Four weeks later, this is what’s on your desk
A proof of concept is only useful if a decision can be made from it after we have gone. So the deliverables are built to be handed on, not to be demonstrated.
A deployed prototype
Running on a real URL, in your cloud or ours. Not a design file, not a demo on a laptop that only works when we are driving it.
Every journey, walkable
Including the wrong turns. Your champion can put it in front of a steering group and click wherever they like without it falling over.
One real integration
Single sign-on, Teams, your ticketing system — whichever proves it fits your estate. This is the part that matters most, and the part most prototypes skip.
A solution design document
The architecture written down properly, so the next team can build it without starting again. Contents below.
A production route and a verdict
What it would cost, how long it would take, where the risk sits — and whether we think you should do it at all.
Inside the solution design document
The prototype proves it can work. This is what lets somebody else build it properly — and what your architects will ask for first.
- System map — Every component and how they talk to each other
- Architecture decisions — What was chosen, what was rejected, and why
- Data model — Entities, relationships, and where each field comes from
- Sequence diagrams — The critical flows, step by step
- User journeys — What each role actually does, screen by screen
- Integration contracts — The interfaces touched and what they expect
- Authentication and access — Who can do what, and how that is enforced
- Data handling — What is stored, where it goes, how long it lives
- Environment and configuration — Every setting needed to run it
- What the proof did not cover — Named explicitly, so nobody assumes it did
System map — representative shape
Every component and every hop, named. The version you receive is specific to your system rather than this generic shape.
We document our own systems this way
This is not a standard invented for client work. Nookaly — our own property analysis product, live on the App Store and Google Play — runs on a microservice backend with asynchronous workers, its own billing, and a browser extension, all self-hosted and operated daily.
It is documented to exactly the standard described above, and kept current, because we are the ones who get called when it breaks. That is the difference between a prototype built to be demonstrated and one built to survive.
Want to see it rather than read about it?
The quickest way to judge this is a walkthrough — a live system, its architecture documents, and the reasoning behind both.