The pieces and their boundaries are settled before code.
Several institutions, one system, records kept apart.
One codebase, both stores: iOS and Android.
We take a running system over and improve it.
AI only where the problem actually calls for it.
Treatment is planned tooth by tooth and split into sessions spread over weeks. An appointment is a scheduled step of that plan rather than an empty slot, so changing the plan moves the calendar. Invoices and reports come off the same patient record.
Dental work rarely finishes in one visit. A plan is drawn tooth by tooth, split into sessions across weeks, and revised along the way. The clinic was running that on a general booking tool: it held the hour, never the step.
Where a patient stood came off the calendar, what had been charged came off a ledger, and the month-end figures came from somewhere else again. What they needed was not more modules. It was the plan, the appointment and the invoice living on one patient record.
We go through how the work runs today and what you expect from the software; the scope comes out of that.
We decide what the system is made of and where its information is kept.
We draw the screens and the flow before any code, and start building once you have approved them.
We write and hand over the software so another team could carry it on.
The plan holds which procedure goes on which tooth, ordered into sessions, and stands as its own record independent of any appointment.
Every appointment points at a specific step of the plan, so adding a session or reordering treatment shifts the calendar with it.
Billing reads the procedures already recorded against the patient, so what was treated and what was charged are never two separate books.
Reports read the same patient record from another angle, so month-end figures need no second round of data entry.
| Challenge | Result |
|---|---|
| Dental treatment rarely ends in one visit; a plan runs tooth by tooth across sessions | Treatment is planned per tooth, with session order held on the plan |
| A general-purpose booking tool records the hour but not the step of a treatment plan | Changing the plan moves the calendar, so no appointment is left orphaned |
| Plan progress lives in the calendar, billing in a ledger, month-end figures somewhere else again | A clinic manager reads plan progress, appointments and billing off one patient record |
| When work done and work billed sit in separate books, reporting becomes manual reconciliation | Reports come from that same record, so nothing is reconciled by hand at month end |
Our own workshop software, built around the car on the ramp. A work order, the parts it consumes and the invoice it produces run as one chain, and the accounting side hangs off that same record. Maintenance history lives on the plate and chassis, so it travels with the car.
Our own product for HVAC, boiler and appliance service companies. The customer and device records the office works from are the same ones the technician carries into the field. A job can be opened and closed in a basement with no signal, and service history stays tied to the device.
Our own product, still in development and not yet live. How long an appointment runs, what it is booked against and how bookings stack all differ by trade, so we are keeping those rules configurable inside the product instead of fixing them in code.
Tell us how the work runs today and we will look at which step could move into software.
