Seven doors and two handles
A staff availability feature with seven endpoints on the server and two of them reachable from the app. Half-built features do not announce themselves; they look exactly like finished ones from the outside.
Counting the doors into one of our own features turned up a number that did not match: seven ways in on the server, two of them connected to anything a person can press.
The feature is staff availability. Read what somebody has offered; save a change to it. Both of those work and the staff app uses them. Then there are five more: the weeks on offer, submitting your availability properly, asking for a change to a week already agreed, listing the requests waiting on a decision, and deciding one of them.
Those five have no screen. Not a broken screen, not a screen behind a setting — none. The rules are written, the data has somewhere to live, the answers come back correctly, and there is no way for a human being to reach any of it.
Half-built does not look like broken
This is the difficult thing about partial features, and it is why we went looking rather than waiting. Nothing is red. The two connected endpoints work, so availability appears to be a feature that exists. If you had asked us last week whether the product does staff availability, the honest answer would have been a confident yes, and it would have been about a third true.
Nobody decided to stop. Work like this gets built server-first — rules, storage, endpoints — and then the screens are a separate job, and the separate job is the one that slips when something more urgent lands. The server half is the half that leaves no trace of being unfinished.
Writing the number down
The fix, for now, is not to build five screens in an afternoon. What a rota approval flow should look like is a decision, not a gap to be filled quickly, and building it blind is how you get a screen nobody uses.
What has changed is that the number is now a test. Seven routes, two callers. If somebody builds the screens, that test fails, and the only way to make it pass is to say so deliberately — which means the day the feature becomes real, it also becomes something we can honestly claim. Until then it is a thing we know about rather than a thing we have quietly forgotten.
Worth asking of your own stack
If you run a venue on software somebody built for you, the question is worth borrowing: for a feature you believe you have, how many of its parts can you actually reach? Not whether the vendor says it exists. Whether you can press it.