An offline-first field app lets a technician create a record where the work happens, queues it on the device without a signal, and sends it to the office system when coverage returns. Where that record comes into being is a data-model decision, which is why offline work cannot be bolted on afterwards. In AlgoKlima the queue drains when connectivity returns, and records arrive in the order they were opened on site.
The record is created on site, while the job happens
In AlgoKlima, a service record is created on the technician’s phone while the job is being done, not retold at the office in the evening. That sentence is one of the product’s founding decisions.
Look at what it replaced. An HVAC, boiler or appliance service business follows three things in three separate places: the customer in an office spreadsheet, the device somewhere between that sheet and a technician’s memory, and the job itself in a notebook the technician carries. A phone line runs between them. At the end of the day the technician describes what happened and somebody at the office types the description. Every handover in that sequence loses something: which part went in, what the serial number was, how the customer phrased the fault. None of it is carelessness. It is what happens when a record is produced hours after the event it describes.
The second face of the same gap showed up in the construction workforce attendance system. There the record lived on a paper timesheet. At month end nobody could establish who worked which site, or for how long; the only evidence was a sheet signed weeks after the fact. When somebody disputes a figure, the argument stops being about the work and becomes an argument about the paper.
Both projects started from the same move: create the record on the phone, in the field, while the job is happening. Everything downstream follows from that: which database it lands in, which screen shows it, which report totals it. What the rest of this article works through is what has to be true for that record to survive the trip to the office.
Coverage ends in the boiler room; the work does not
AlgoKlima’s technicians do their actual work in boiler rooms and elevator shafts, where losing signal is a normal working condition rather than a fault.
The practical consequence is blunt: the job happens precisely where the connection is not. A service call goes out to a boiler, the boiler sits in a plant room, and the plant room is in the lowest part of the building. Lift shafts belong to the same category. Losing signal there is a property of the place the work happens.
Building for that means changing the question. “What do we do if the connection drops?” describes a failure case, and the answer usually turns out to be a warning screen, because the problem has been filed as temporary. “How do we work when there is no connection?” reaches into the data model instead, and the answer is a decision about where the record is kept rather than a screen. The two questions do not produce the same product.
There is a middle position worth naming, because it passes for offline support without being it. Holding the form in memory and retrying in the background still treats the connection as mandatory: when the retry fails, the record still belongs nowhere. Creating the record on the phone removes connectivity from the record’s conditions of existence. In the first case the connection is late. In the second it is beside the point.
You can see the difference in the technician’s hands. A form that waits for a network stops the technician in the middle of the job it was supposed to capture. With no way to enter the record, two options remain: the work waits, or the record waits. The second one gets chosen, and choosing it walks straight back into the previous section: the job described at the office that evening, with half of it missing.
The counter-case is just as clear. Where the whole job happens inside coverage and at a desk, an offline layer is complexity with no return. Building a local queue for a team working on a tablet in a showroom leaves behind something that has to be maintained and never earns its cost. What settles it is where the team physically stands while working, not the industry it works in.
With no signal, the record goes into the phone’s local queue
When AlgoKlima’s field app has no connection, a new record is written to the phone’s local queue first, and the rest of the app treats it as a completed record.
The technician opens and closes a job outside coverage. The app keeps working without waiting, because the write finds its destination inside the phone. This is a founding decision: it fixes where the record is first written, which is exactly why it cannot be added afterwards. Making a server-first app work offline is not a matter of adding a screen. It redefines the record’s identity, its ordering, and its behaviour when two versions of it meet.
The status of a queued record is the part that matters. As far as the rest of the app is concerned, that record is finished: the technician moves to the next job and the queue waits for a connection in the background. No “failed to send” banner appears. Suppressing it puts responsibility where it belongs rather than hiding a failure. Keeping the record accurate is the technician’s job. Moving it is the app’s.
Creating the record on the phone has a second consequence: the ordering information is created there too. Because the record comes into existence on the device, the moment it came into existence is known on the device, and nothing at the office has to infer it from arrival times. On a server-first design, order is a function of when data lands, so two jobs done back to back in the field can reach the office in the wrong sequence.
The counter-case exists here as well. A queue model does not suit work that requires the record to appear at the office immediately. If a dispatcher has to watch a field step live, the queue introduces a delay. That delay is not a defect in the mechanism; it is the mechanism’s definition, and a business that wants it removed is asking to give up offline operation.
Three field conditions, side by side, and what each one does to the record.
| Field condition | Where and how the record is created | What happens when it reaches the office |
|---|---|---|
| A service point outside coverage — boiler room, lift shaft | The technician opens and closes the job on site; the record is written to the phone’s local queue first | Once the signal returns the queue empties in creation order, and office and field edits are reconciled into a single record |
| A temporary construction site — no fixed hardware, crews moving between projects | The check-in is created on the worker’s phone at the moment of the QR scan, with the site written into the record then | Laravel receives it and MySQL stores it; time on site comes from a matched entry and exit, and an open entry stays visible as incomplete |
| A workshop — the job starts when the car comes in and the chain runs indoors | A work order is opened and each consumed part is booked against it | The part leaves stock as it is booked, the invoice comes off the same record, and cost and revenue close in one system |
What the rows share is that the record and the work happen at the same moment. What differs is what the record carries with it once it arrives.
When the signal returns, the queue empties in creation order
In AlgoKlima, synchronization is triggered by connectivity returning, not by the technician pressing a send button; the queue drains in creation order.
Preserving order is a factual requirement rather than a nicety. A technician opens and closes several records inside one building. If those records arrive in an arbitrary sequence, the chronology of the day falls apart: which fault was seen before which, which part went into which job. Those are ordering facts, and losing them costs more than losing a timestamp.
The rule protects a common case. A technician servicing several units at one address opens a separate record for each. Had those records arrived in whatever order the network allowed, the only way to rebuild the sequence would be to read a time field and hope it was reliable. Because the queue carries the order already, nothing at the office has to be corrected afterwards.
There is no separate send step, and its absence is deliberate. Had sending been manual, the evening batch-entry problem would have come back wearing a new costume: evening batch-sending. Everything gained by creating the record in the field is handed back the moment the transport step becomes the user’s problem, because the user is the person in a van at the end of a long day, already thinking about the next call.
When both sides edit one record, the merge leaves one record
When AlgoKlima’s office panel and field app change the same record independently, conflict resolution merges both sets of changes into a single record rather than leaving two copies.
The situation is routine rather than exotic. While the technician is out of coverage, the office updates the same job: the appointment slides, the customer adds a request over the phone, an address note gets corrected. Two parties edit the same record without knowing about each other, and each has a good reason.
When the connection comes back, the changes made in the field and the changes made at the office are reconciled into one record. From the user’s side the consequence is simple: the conflict is not handed back to the technician as an error. Reconciliation runs as an ordinary step of synchronization.
Thinking through the alternative makes the mechanism legible. Asking the user to resolve it, keeping either the field version or the office version, gives the decision to the person who has just walked back into coverage and is already halfway to the next job. Worse, the question forces a wrong answer in every case where both edits were correct: picking one deletes the other. Merging asks fewer questions and loses less data.
The boundary is worth stating. Conflict resolution operates at the level of the record. Two sides making contradictory business decisions at the same time, such as the same job assigned to two technicians, is not something the software settles; that belongs to the operation. The software makes the record single. It does not make the decision single.
A record created in the field keeps the chain intact
In AlgoCar, a consumed part is deducted from stock the moment it is written to the work order, and the invoice is issued from that same record.
The value of a field-born record does not stop at the moment it is created. The real question is what happens to it next: does the same information get keyed a second time, or does the rest of the chain run off the original?
In AlgoCar the chain runs off one record. A work order is opened, the parts it consumes are booked against it, and the invoice comes out of the same place. Booking a part takes it out of stock immediately, so nobody re-enters the warehouse movement on a separate screen. The cost and the revenue of a job never have to be matched between two programs at month end, because they sat on the same record the whole time. Since the stock movement hangs off the work order, no bridge had to be built to the invoicing side afterwards.
One boundary belongs here. AlgoCar is workshop software: the job starts when a car comes onto the ramp and the record chain moves indoors. This section does not attribute offline operation to AlgoCar. It shows what a record created in the field is worth downstream: wherever a record is created, whether the rest of it travels on one chain is a separate design question with its own answer.
The opposite arrangement is familiar enough: the work order in one program, the parts store in another, the invoice in a third. In that shape even a record created in the field gets retyped at the office. The only thing offline capture buys is that the data is entered earlier and then entered again. The mechanism works, and the gain is handed back at the second link in the chain.
On a temporary site, the record belongs to the worker’s phone
In the construction workforce system, a check-in is created on the worker’s phone the moment a QR code is scanned, so a temporary site needs no installed turnstile.
A construction site is temporary by definition. Putting up a turnstile means taking it down again when the project closes. Crews are not fixed to one site either; the same worker can be somewhere else by midweek. Had the record been tied to a device, the recording infrastructure would have had to come down with the site, and as workers move between projects, which device holds which record turns into a question of its own.
So the record is created on the worker’s phone. Scanning the QR code produces the check-in, and the site the worker is on is written into the record at that moment; the site name is never chosen from a list by hand. When the project closes, nothing has to be removed from the site, because nothing was installed there.
Time on site comes from a matched entry and exit. An entry left open stays visible as an incomplete record until its exit scan arrives. An unclosed record is not quietly completed by the system; the gap stays on the screen where somebody can see it.
The second face of the hardware decision is about movement. A fixed reader ties the record to the point it stands at, so a worker who does not pass that point produces no record at all. A phone travels with the person, which is why the same worker’s records on different sites stay separate. The record belongs to the person carrying the phone.
The counter-case is sharp here too. On a single permanent facility, with a stable crew and one entrance, the advantage of a phone-centred model disappears. A fixed reader there means fewer moving parts. This is a model built for sites that come and go.
The office panel and the field app read one database
AlgoKlima’s office panel runs on Laravel with Inertia and its field app on React Native (Expo); both connect to the same MySQL database, with Redis carrying the cache.
That sentence says where the mechanism sits. The offline queue is not a separate system standing beside the platform; it is the field end of the same one. The office panel and the field app do not keep their own copies; they read the same customer and device record. Had separate copies been kept, the rule deciding which copy counts would have had to be written into the middle of the system later, once there were already records to disagree about.
Keeping one stack has a concrete payoff at exactly this point. Because the field app and the office panel read the same database, a record released by the queue settles into place without a second transformation. Put the two sides on separate systems and there is another transfer layer at the end of the queue, which conflict resolution would then have to account for as well.
The same arrangement runs on the construction side: the React Native (Expo) app sits on the worker’s phone, Laravel receives the records, MySQL stores them. The pattern is not specific to one project. Every phone app we build is React Native (Expo), and each one talks to the Laravel application the office side already uses. Rather than choosing a stack per project, we stay on one set we can keep maintaining for years.
The local queue is designed on the mobile app side of the work: how a record comes into existence on the phone, in what order it travels, and how a conflict closes are all settled there. Its counterpart at the office sits in business process tracking, where the same record is read from a surface with different permissions.
Which leaves one question worth asking about any field app: where is the record created? If the answer is the phone, connectivity is a condition, and the work continues when it drops. If the answer is the server, connectivity is a dependency, and when it drops the record goes with it.
