How we build it
Research-led. Clinician-guided.
You cannot judge our product yet. You can judge how we go about building it, so here is our working.
We studied the incumbent before we drew a single screen.
Before any design work, we pulled apart the practice software New Zealand dental teams use every day. Module by module. Screen by screen. Counting the clicks that ordinary tasks take.
Then we mapped the real journeys end to end: a patient booked, seen, charted, charged, claimed for and recalled. We marked every point where the system makes a person do its work for it.
We know where the friction is because we measured it, not because we assumed it. That structured teardown is what we mean by research-led: a workflow analysis of the systems in use, not a survey of opinions about them.
A module isn’t finished when it works.
It is finished when a practising clinician has used it in the conditions it was built for and told us it is better than what they had.
Dental is where we developed the clinical framework, and dental clinicians shaped it. We say built with clinicians and tested against real workflows, deliberately, and not “clinically validated” or “clinically proven”, which mean something specific that we are not claiming.
We built the hard parts first.
The tempting way to build practice software is to start with the demo-friendly surface and leave claiming, compliance and clinical depth until later.
We went the other way. The claiming spine and the chairside loop were specified first, because that is where the day is actually won or lost, and where a shortcut cannot be hidden for long.
How we build it