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 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.
Work in a repair shop starts when a car comes up the ramp, then the record splits three ways: the job in one program, the parts store in another, the invoice in a third. Cost and revenue get matched by hand at month end, and history filed under the customer stays behind when the car is sold on.
We built AlgoCar as our own product and we run it ourselves. The vehicle sits at the centre of the data model: the plate and chassis record is where the workshop side and the commercial side meet.
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.
A job opens, the work done and the parts used are booked against it, and the invoice comes out of that same record; no link in the chain moves to another program.
Booking a part to a work order takes it out of stock straight away; nobody re-enters the same movement on a separate store screen.
Maintenance and repair records hang off the vehicle record, so a car carries its own history when it moves to a new owner.
The business and accounting side sits with the service record, so nobody reconciles two programs' reports at the end of the month.
| Challenge | Result |
|---|---|
| A workshop keeps work orders in one program and parts stock in another | Work orders and the parts store live in one system, not two |
| Invoices come out of a third system, so cost and revenue meet late | The invoice comes off the same work order, so cost and revenue close in one place |
| Parts consumption gets typed twice: once on the job, once in the store | Stock moves when a part is booked, with no second entry |
| History filed under the customer disappears when the vehicle is sold on | When a car is sold on, its maintenance history goes with the plate and chassis |
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.
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.
AlgoCar is live. Write to us to ask what it covers or whether it fits your work.
