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.
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.
Most appointment software is written around one trade. But a booking is not the same object everywhere: how long it runs, what it is held against, and how bookings stack all change between a clinic, a salon and a workshop. That leaves a business bending its own process to fit the software, or running bookings out of a calendar and a message thread.
We are building AlgoRandevu to take that choice away. Appointment rules go into product settings rather than being baked into a sector, so changing one does not mean touching the code. The product is still in development and has not launched.
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.
Slot length and the gap between bookings are going into product settings rather than code, so changing a rule does not need a release.
In the structure we are working on, a booking attaches to a person, a room or a piece of equipment, and the business picks which resource applies.
The product sits on the Laravel and Inertia foundation behind our other panels, so a business already using one of them finds the screen logic familiar.
| Challenge | Result |
|---|---|
| Most appointment software is shaped around how one trade books, and fits nothing else | Appointment rules go into product settings, so there is no build to ship per sector |
| Slot length, and the gap left between two bookings, differ in a clinic, a salon and a workshop | Slot length and the gap between bookings will be set by the business, not by us |
| An appointment may be held against a person, a room or a piece of equipment | A booking will attach to a person, a room or a piece of equipment |
| So a business either bends to the software or runs bookings by calendar and messages | The aim is to replace calendar-and-messages booking with a single panel |
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.
A single-page QR menu. The menu splits into sections and every section carries its own address, so the code on a table and the code in the window open the page at different points. Built with Vue 3, moving between sections costs no new page request. No ordering, payment or stock layer.
AlgoRandevu is not live yet; we are building it now. You can send us your question about it.
