RevierLog is a documentation system for the winter-service and facility companies that clear and grit the walkways, entrances and yards a German property owner is legally required to keep safe. Its subject is not the clearing — it is the record of it. Which surface, worked by whom, from when until when, and in what weather. The driver’s phone records the run while the run is happening, the track is matched against the surfaces drawn once for each property, and the official German weather service’s reading for that region is captured at the moment of the run and never rewritten afterwards. What comes out the other end is a consecutively numbered protocol for the property manager, a defensible line on the invoice, and an answer ready for the day somebody asks whether the site was actually cleared.

StatusPre-launch — pilot waiting list open
Availabilityhttps://revierlog.de
NameRevierLog
GenreField Documentation / B2B Web and Mobile Application
Subsidiary

Project Highlights

Recording that begins and ends with the job. There is no background tracking and no always-on fleet view: the driver starts the run and ends it, and that bracket is the only window in which position data is written at all. This is a product decision before it is a technical one. A tool that records a working day is a different thing, legally and socially, from a tool that records a job — and only the second one can be introduced into a small business without a fight.

The weather, frozen to the run. Every run carries the official weather situation for the property’s region — temperature, precipitation, ice warning — captured at the time of the run and then left alone. Weather services correct their readings afterwards; RevierLog does not overwrite the original when they do. The final measurement arrives as its own row with its own retrieval time, so the record shows both what was known then and what was established later. An amended record is a weaker record than an appended one.

Protocols that hang together. Each protocol PDF carries a consecutive number and a checksum of the one before it. Remove a protocol or alter one after the fact and the chain visibly breaks. The point is not cryptographic theatre — it is that the property has a document set whose completeness can be demonstrated in a sentence, by someone who did not study computer science, to someone who did not either.

A gap in coverage costs nothing. Every measured point is written to the device first and uploaded when the connection returns. Underground car parks, industrial estates at four in the morning, valleys with one bar — the field does not get to promise connectivity, so the client does not depend on it.

The effort is paid once, at the start. Setting a property up means tracing its clearing and gritting surfaces on aerial imagery. The square metres are calculated from the outline, and the priority ordering decides what gets done first. After that, the documentation is a by-product of the work rather than an additional task at the end of the shift — which is the only form of documentation that actually survives a bad night.

Retention the operator controls, deletion that writes itself down. How long individual measured points are kept is set by the business, not by the vendor; a daily job removes what has aged out and records what it removed. Finished performance records are untouched by it, because the two answer to different rules: raw position data is personal data with a purpose that expires, a completed proof of work is a business record that does not.

Prices on the page. The tariffs are published, and a calculator on the site works out what a given number of vehicles and properties would cost. It runs in the visitor’s browser; nothing about it is transmitted or stored. For a trade used to “call us for a quote”, that turns out to be a feature.

Technologies Used

Public site: Astro, static-first — the landing page ships as HTML and a single stylesheet, with exactly one interactive island for the price calculator. Nothing on the page needs a framework to render, and the calculator needs no server.

Field client: ordinary smartphones, Android and iPhone. No in-vehicle hardware is required, installed, or sold — the recording runs on the device the driver already carries, with local-first writes and deferred upload.

Geometry and matching: property surfaces are stored as drawn polygons with computed areas and a priority order; a recorded track is assigned to them automatically, producing a worked-from/worked-until interval per surface instead of a scatter of dots on a map.

Data residency: application, database and files sit with European providers — servers in Falkenstein, database in Frankfurt — which keeps the question a property manager asks about data location to a one-sentence answer.

Output: protocol PDFs with consecutive numbering and predecessor checksums, plus a billing export, both generated from the same run data rather than re-entered.

Challenges and Solutions

A record is worth what it survives. The hard requirement is not “store the data” but “be able to show the data was not touched since”. The answer is three plain mechanisms rather than one clever one: raw data that is never edited, a weather snapshot that is appended to instead of corrected, and a numbered chain of protocols that breaks visibly if a document goes missing. Each is explainable on its own — which matters more than elegance when the explanation happens in a room full of non-specialists.

Recording work is a sensitive thing to build. The obvious architecture — track the vehicles, derive the jobs — is the one that makes the product unsellable to the crews who have to use it. Inverting it, so the driver’s start and stop define the recording window, costs some analytical convenience and buys the thing the product actually needs: a driver can look at it without feeling watched.

Two calendars of truth for the weather. A reading taken during a run and a reading published later are both correct, and they disagree. Rather than picking one, the record carries both with their retrieval times and lets the reader see the difference. Silently replacing the first with the second would have produced a tidier database and a worse document.

Buying software in this trade is normally a negotiation. Winter-service contracts are signed in late summer, from a standing start, by owners who do not want a sales process. Publishing the tariffs and putting the arithmetic in the browser removes the step where a small operator has to identify themselves just to find out what something costs.

Future Directions

Hardware trackers are on the map as an optional supplement for operators who want them — never as a precondition, which would change what RevierLog is. Beyond the winter module, the same recording and proof mechanics apply to year-round grounds maintenance, and the template system is built with that in mind. The pilot decides the order: what the first operators reach for gets built next, and what they never open gets written down as declined.

Conclusion

RevierLog is a small product with an unusually exacting requirement: its output has to be believable to someone who was not there and has reason to doubt it. That shapes everything upstream — recording bounded by the job, weather appended to rather than corrected, protocols that account for each other, retention rules the operator can defend. The clearing is done by people with shovels and spreaders at four in the morning. The software’s whole job is to keep that work visible months later, when the only thing left of that night is the record.

Join the RevierLog pilot waiting list