
Andre Ochoa
2026-06-08
PRD-0034
I spent a full day writing 10 implementation units for a dental booking calendar. For 3 dentists. It's not over-engineering. It's the audition.
Two friends of mine consult for dental clinics. They're in the trenches. They know the owners, they see the pain, they have the trust.
We started talking. We're building Striva, a finance platform for small businesses in Portugal. We needed a vertical. They had the vertical. Perfect match.
But they were honest from the start: the clinics already have software. It looks like it's from the 80s, it's clunky, the owners complain about it constantly. And they won't switch.
Not because they love it. Because it works. It's entrenched. They know how to use it. And the one feature that makes or breaks their day, the agenda, is good enough to keep them locked in.
If we want their clinics to switch, the agenda has to be substantially better. Not incrementally. Not "a bit nicer." Better enough that a clinic owner looks at it and says: yes, this is worth the pain of changing everything.
That's the audition. You don't get to show the AI. You don't get to show the invoicing. You don't get to show any of it until the agenda earns the right to exist on their screen.
So I spent a full day writing PRD-0034.
Ten implementation units. Slot-intent suppression, so when a receptionist clicks a time slot directly, the system shuts up and doesn't try to suggest a better one. A single Book button instead of two competing paths. Empty states that are never dead ends. Peel a filter, extend the range, try another doctor. Short-gap warnings that advise but never block. Drag-and-drop that respects the clinic's actual closing hours, not a hardcoded 8-to-9.
258 tests. Adversarial code review. One persona checking correctness, another checking race conditions. Pure functions extracted so nothing hides inside component state.
For a dental booking calendar. For three dentists.
It sounds like over-engineering. It's not.
My friends won't put their name behind something that embarrasses them. They built trust with these clinic owners over years. One bad demo and that trust is gone. They're not going to risk it for "pretty good."
The incumbent software is ugly but bulletproof. Every edge case has been handled by ten years of receptionists complaining until it got fixed. We don't have ten years. We have one demo.
So the agenda has to be right. Not eventually right. Right now. Every workflow, every edge case, every moment where someone could get confused or stuck. Resolved. Because the person at the front desk is going to test it for a week, and she's going to find every crack.
She did find cracks. After the first demo my friends came back with a list. The booking flow was confusing. The calendar was hard to scan. Two colour systems fighting each other, block fills saying one thing while badges said another. The modal was cluttered.
That's what PRD-0034 fixed. Not features. Cracks.
We started from an open source dental management project. That was the foundation. But foundation isn't product. Product is the craft you put on top. The decisions about what happens when a drag-and-drop lands near closing time. The decision that a filter should peel off one at a time instead of clearing all at once. The decision that a short gap between appointments should warn, not block — because the server catches real conflicts anyway, and the receptionist knows her clinic better than your validation logic.
These aren't features anyone will list on a comparison page. Nobody will tweet about slot-intent suppression. No one will demo the never-empty empty state at a conference.
But she'll feel it. She'll book an appointment and nothing will fight her. She'll look at the calendar and it'll make sense. She'll try an edge case and it'll have an answer.
And she'll tell the owner: this one's better.
That's the only review that matters.