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.
An HVAC company's site receives two unlike requests: a pre-sale site survey and a post-installation service call. Each runs as its own intake flow inside the same Laravel application as the marketing pages, so requests reach the team already separated.
Visit the site →Diotek installs and services air conditioning and ventilation systems. Two unlike requests reach a company like that. One comes before a sale: capacity depends on the room, so someone has to see the space before anyone quotes a unit. The other comes after installation, and it is about a machine already on the wall.
Both used to arrive on one phone line, and at season peak they piled up. We build AlgoKlima as our own product for HVAC, boiler and appliance service work, so we knew before writing a line why a survey booking cannot behave like a maintenance call.
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 visitor asks for a date before choosing any equipment, and that request travels its own path, separate from the service queue.
Maintenance and fault reports open from the site around the installed unit, so the record is written down rather than kept as a phone note.
Inertia handles page transitions in the browser while routing and validation stay in Laravel; requests and content share one MySQL schema.
Redis absorbs the traffic spike at the start of a season, and the intake screens run on the same Tailwind scale as the public pages.
| Challenge | Result |
|---|---|
| Unit capacity depends on the space, so a survey has to precede any quote | A visitor books a site survey before choosing any equipment |
| A survey request is about a room; a service request is about an installed unit | Maintenance and fault requests open from the site through a flow of their own |
| Both arrived on the same phone line, and only a conversation told them apart | At season peak the two request types reach the team already told apart |
| When the line was busy at season peak, the visitor on the site left | Intake no longer depends on the phone line, so a visitor who finds it busy still leaves a record |
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.
