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.
Three kinds of content behave differently here. A forecast is overwritten on every refresh, a past day is written once and never changes, and a climate summary is recomputed as the archive grows. Every date and location holds its own permanent address.
Visit the site →A weather site carries three kinds of content that behave nothing alike. A forecast is written over on every refresh. A recorded day is written once and never touched again. A climate summary changes only because the archive grew.
Publish all three the same way and you either serve stale forecasts or rebuild pages that should have stayed frozen. We separated the three: a forecast ages into an archive row, and the summaries are read back out of that archive.
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 forecast is refreshed and each update overwrites the last; once a day's date passes, that record moves into the archive.
Each past day sits at its own permanent URL, written once and left alone, with a measured day replacing what had been a forecast.
Summaries are not fed from a separate source; they are computed from the stored day records, so a growing archive rewrites them.
Every location's every day is published at its own address, and adding more of them does not call for restructuring the site.
| Challenge | Result |
|---|---|
| A forecast is overwritten on every refresh; a recorded day must never change again | Today's forecast is not deleted when it expires; it becomes an archive row |
| Climate summaries are not fixed text: they have to be recomputed as the archive grows | Climate summaries update themselves as the archive grows, with no manual rewrite |
| Publishing all three the same way leaves stale forecasts or needlessly rebuilt archive pages | Forecast, archive and climate summary each behave differently: no stale forecast, no archive page rebuilt for nothing |
| Every date and location needs a permanent address the archive can keep growing into | Every date and location combination keeps its own URL, and the site deepens as the archive fills |
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.
