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. The QR code printed on a card points at one fixed address, while the page behind it is edited from a panel. When a number, a job title or an address changes, the record is updated and the box of cards stays valid.
A business card is printed once. The business it describes is not. A new phone number, a new job title, a move across town, and a full box of cards is suddenly wrong, so either the old details keep circulating or the whole run gets reprinted.
We are building QRVizit around one split: the code is permanent, the content is not. The address printed on the card never moves, the page it opens is edited from a panel, and whoever scans it installs nothing. QRVizit is in development and not yet live.
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 QR code points at one address that is printed once and never moves; the text, the links and the contact details behind it are edited from the panel.
The phone camera opens the page directly, with nothing to install; Tailwind keeps the layout readable on the small screen it lands on.
The admin panel and the visitor page live in one Laravel app; Inertia feeds the React interface, so no separate API layer sits between them.
Page content is cached in Redis, so a code scanned thousands of times does not send every scan down to MySQL, where the records live.
| Challenge | Result |
|---|---|
| A card is printed once, while the business it describes keeps changing | A change of detail is an edit to the record, not a new print run |
| A new number or job title turns a full box of cards into waste | The printed code keeps working while the page behind it changes |
| Asking someone to install an app to read a business card defeats the card | Whoever scans the code installs nothing; the camera opens the page itself |
| One code can be scanned thousands of times, and every scan cannot hit the database | A code scanned thousands of times is answered from cache, not the database |
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.
QRVizit is not live yet; we are building it now. You can send us your question about it.
