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.
A selection and quoting tool for an electric heater manufacturer. The user states a heating requirement instead of a part number; the software runs the engineering calculation, and the heater it picks becomes a line on the quote.
Visit the site →Resterm manufactures electric heaters. Getting the size right is an engineering calculation; writing the quote is a commercial job, and in most companies those two sit at different desks. So the problem the software had to solve was never really the maths. It was the gap between the desks.
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.
What goes in is the requirement itself. The application runs the engineering calculation and comes back with the heater that meets it, so nobody browses a product list.
The selected heater drops into a cart, the cart belongs to a project, and that project to a customer, one chain held in MySQL.
Nobody retypes a figure between the technical selection and the commercial line, and any quote can be read back to the requirement that produced it.
We built the application around how Resterm structures its products, with Laravel behind the calculation and records and Vue driving the interface.
| Challenge | Result |
|---|---|
| Sizing a heater takes a calculation, and the person quoting is rarely the person calculating | The requirement goes in and the software answers with a sized heater |
| The maths sits in a spreadsheet, the catalogue in a file, the quote somewhere else | Calculation, catalogue and quote stop being three places and become one chain |
| Once selection and quote line come apart, nobody can say which figure produced which item | The calculation output becomes the quote line, and any quote reads back to that figure |
| Bolting a catalogue onto a generic quoting tool does not carry a manufacturer's product structure | The catalogue carries the manufacturer's own product structure, not a generic tool's |
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.
