The business
A multi-site allied health practice with about thirty clinicians, most part-time, most working across two or three locations. Rostering was a spreadsheet.
Not a small spreadsheet. Fourteen tabs, a decade of accumulated formulas, colour coding that meant something to exactly one person, and a set of macros written by a practice manager who had since gone part-time herself. It held clinician availability, participant appointment patterns, and enough personal information to matter.
It also could not be opened by two people at once, which meant rostering happened in a queue.
The first thing we did was ask if they should buy something
There are good rostering products. We spent the first two days working out whether one of them fitted, because if it had, the honest advice would have been to buy it and we would rather give that advice than take the work.
It did not fit, for a specific reason: the practice runs a funding model where a participant’s allocated hours have to be tracked against a plan, and clinician allocation has to respect continuity rules that are clinical rather than administrative. Off-the-shelf rostering treats staff as interchangeable resources. Here they are not, and the gap was exactly where the value was.
So we built. But we only knew that because we checked, and we told them what we checked.
The wish list, and the third we removed
The initial wish list had nineteen items. The first release shipped with twelve.
The seven we removed were not removed because we ran out of time. They were removed in the shaping session, deliberately, and written down by name in the brief as things this release does not do. That list is the most valuable box on the page, because everything on it is something nobody argued about in week eight.
The feature we talked them out of entirely
One request was participant-facing: let participants see and change their own appointments through a portal.
Genuinely useful. Also a completely different security proposition. The internal tool authenticates staff through the practice’s existing identity provider, and every user is an employee with a contract and a background check. A participant-facing portal means public registration, credential recovery for people who may have cognitive impairments, and a login page on the open internet in front of health information.
That is not a feature. It is a second product with its own threat model, and bolting it onto release one would have compromised the security design of the thing they actually needed first.
We said so, explained why, and they agreed. It is still not built. It may be one day, and if it is, it will be scoped as what it is.
Designing the data before the screens
Before any interface work, we wrote down what the system holds, who can see it and how long it is kept.
That produced one decision that shaped everything: clinicians can see participant names and appointment history for their own participants, and availability only for everybody else. It sounds obvious written down. It was not how the spreadsheet worked, where anyone who opened the file saw everything in it, because a spreadsheet has no concept of a row you are not allowed to read.
Getting this on paper first is the difference between security being designed in and security being a review that finds problems too late to fix cheaply.
The security review
Before launch the application was tested by the same people who do our penetration testing. Included, not an extra.
They found three things. One was a genuine access control gap on a reporting endpoint that would have let a clinician pull a summary across participants who were not theirs, which is precisely the rule the data design existed to enforce, missed in one place.
It was fixed before anyone used the system. Finding that after launch, in an application holding health records, is a different kind of week entirely.
Nine weeks later
The practice manager no longer owns rostering as a personal responsibility. Two people can edit at once. The funding hours tracking that used to be a monthly reconciliation is now a number on a screen.
The code and infrastructure belong to the practice. The documentation is written so another developer could pick it up, which is deliberate. We would rather keep a client because they want to stay.
The point of the story
Most of what made this project work happened before any code: checking whether they should buy instead of build, naming the seven things the first release would not do, and declining the one feature that would have changed the security proposition entirely.
Software with no edges is how a fixed-price build turns adversarial. Writing the edges down, by name, is the whole trick.
The details above are a composite and the identifying details are changed. The short build brief is the worksheet we use in that first session, and you are welcome to fill it in before talking to any developer, including us. The Custom Software and Integrations page walks through how an engagement runs.
