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 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.
Visit the site →Someone reading this menu is standing at the counter or sitting at a table, on their own phone, on whatever connection reaches inside the shop, deciding in a few seconds. A photo or a PDF asks them to pinch and wait. A printed card means a reprint every time a price moves.
Nothing here needed a big system: the job was one page that opens fast, reads on a phone and can be edited when prices change. It is the smallest piece of work in this portfolio, and one of the clearest briefs in it.
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 menu splits into sections and each one carries its own anchor, so separate QR codes land on different parts of the page.
Once the menu has loaded, moving between sections asks for nothing new, so the wait on a weak connection happens once.
Share the link to a section and it opens at that section for the other person too, with no scrolling from the top.
The menu is text on a page, so a price change is an edit rather than a print run, and the same QR code stays valid.
| Challenge | Result |
|---|---|
| Someone reading the menu is at a table, on their own phone, deciding in seconds | The code on the table and the code in the window each open the right section |
| Connections inside the shop are often weak, and a slow page gets closed | The menu loads once; moving between sections needs no new request |
| A photo or PDF menu asks for pinch-zoom and opens late on a phone | The menu reads on a phone screen without pinching or waiting for a file to open |
| A printed menu means a reprint every time a price moves | A price change stops being a print job and becomes a single edit |
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.
