The product as we understood it
Our reading, in one page: what the product is, the path the data takes, the two phases, and where each phase runs.
Everything behind the estimate, laid out so you can read it at your own pace rather than on a call. We built a model of your product from your Product Overview, your answers of 28 July and your V1.0 designs, and read the three against each other. Where they disagree, this is where we say so.
Two sheets that say what we think we are building. If anything here is wrong, everything downstream is wrong with it — so this is the pair worth arguing with first.
Our reading, in one page: what the product is, the path the data takes, the two phases, and where each phase runs.
What the platform does, grouped by domain rather than by how it is built — shaded by phase and by whether it is inside the estimate.
The August pilot is the part we can start on now. Nothing in it waits on access to a system somebody else controls, which is what makes the date reachable.
The staffing behind the August window: hours per role per week across the five weeks, rather than one number. The shape is the part you can check.
| Who is on it | Hours | FTE | W1 | W2 | W3 | W4 | W5 | What the line is |
|---|---|---|---|---|---|---|---|---|
| Backend and integration | 180 | 0.90 | 40 | 40 | 40 | 40 | 20 | Carries the analyst by decision — the working sessions with you and the section-to-source mapping ride here. |
| Frontend | 125 | 0.63 | 25 | 25 | 25 | 25 | 25 | The frame around every screen, the patient overview, the assistant entry points. This is the role that paces the phase. |
| QA | 85 | 0.43 | 15 | 15 | 15 | 20 | 20 | A decision about how much verification the pilot buys, not a disagreement about the work. |
| Project manager | 75 | 0.38 | 15 | 15 | 15 | 15 | 15 | One contact on our side for the whole window, as you asked for. |
| Platform and DevOps | 32 | 0.16 | 20 | 12 | · | · | · | The environment first, then quiet. |
| Architect · SA/TL | 25 | 0.13 | 5 | 5 | 5 | 5 | 5 | Five hours a week against the pacing role. |
| The team | 522 | 2.61 | 120 | 112 | 100 | 105 | 85 | |
| Budget | — | |||||||
Five weeks, twenty-five working days, 2.6 full-time equivalents. Not six part-timers — a small team with one role paced against another. Rates and commercial terms come separately, so this stays a technical statement you can check against the scope it is quoted for.
Three zoom levels, both phases next to each other, plus the container reference. It sits in this section because the pilot is the left-hand column — but read the whole sheet: the point of drawing the phases together is the difference between them.
How a doctor moves through the pilot, and the frame that persists around every screen. Solid arrows are drawn in your designs; dashed amber ones are our reading.
V1.0 is the same screens over materially more depth. Most of what gets added renders nothing — which is the honest answer to why V1.0 costs several times the pilot while looking much the same.
The same route one phase later, drawn to the same shape so the two can be read down the page. Its finding is sharper than the pilot's: on the V1.0 route, none of the hops is drawn in the delivered file.
What actually goes to a model, the classes of question it has to serve, the licence filter that removes most candidates before any evaluation, and the named ones that survive it.
Where every fact on the screen comes from, what hangs off what, the six catalogues behind the pickers, and the three ways a clinician can be authorised against your record systems.
These four sheets are the reason the V1.0 figure is a range. Almost every open item belongs to V1.0 rather than to the pilot — which is why we would rather start the pilot and close these alongside it than hold everything until they are closed.
Nothing here needs a meeting. Answering in writing, sheet by sheet, is fine.
Contradictions, not doubts. Each card quotes both sides — your written answer and your own design — and puts our proposed reading underneath, so you can correct it in one line.
Screens that exist in the designs and that no document explains. These carry our assumptions rather than proposals — we had to assume something to price it, and here is what we assumed.
Sign-in and everything around authorisation, error states, the audit viewer, user administration, source selection, language, settings. Each traced to what requires it.
The four clinical readings your screens make, and the two different products the answer picks between. This is the single question with the widest effect on both the figure and the device conversation.