Blog · Industry
How a favour for a colleague became Wintertrace
The story behind Wintertrace: a colleague asked for GPS-backed proof on his side job, and it grew into open-source winter service software built in the open.
Wintertrace didn’t start as a product. It started as a favour.
About five weeks ago, a colleague of mine — Julian — asked me something while we were talking about “vibe coding”, the loose habit of building software by steering an AI rather than typing every line yourself. Julian runs a small winter service on the side, and he wanted to know whether I could put together something to record his work. Mostly just that: a log of what was done, ideally with a GPS track, as proof.
That was the entire brief. Record the work. Add GPS. Keep proof.
I said yes. And then, more or less the same afternoon, I decided to make it considerably bigger than the favour actually required.
Why bigger, and why two languages
Why bigger? Honestly — because I wanted to. The same day, I started building with Claude Code and a planning workflow called Get Shit Done (GSD), and it was clear fairly quickly that I’d rather build a proper piece of software than a one-off script for one person.
The two-language question has an equally simple answer. German as Schneespur, English as Wintertrace, from the start — why not. Both names point at the same software underneath; only the wording, the examples, and the legal vocabulary differ. If I was going to build it properly anyway, building it for more than one country cost little extra at the beginning and would have been painful to bolt on later.
One project quietly became three
It didn’t stay one project for long. It was three almost immediately:
- the software itself,
- the German website, schneespur.de,
- and this one, wintertrace.com.
Two websites for one piece of software sounds like overkill. But Schneespur and Wintertrace genuinely speak to different readers, in different languages, under different legal expectations. A straight translation would have served neither well.
Then came the update problem
Once the software existed, an obvious question turned up: what happens when it gets new features?
How do I deliver an update? Does every operator have to reinstall from scratch, or upload the new files over FTP and overwrite the old ones by hand? And how would I even reach the people who’d installed it to tell them an update exists?
So the software needed to update itself. But an auto-update needs somewhere to fetch updates from — a server that knows which versions exist and hands them out safely. That became jenni.noschmarrn.dev: a small service for hosting downloads, updates, and modules. I want to release it as open source in its own right one day, at jenni.download.
The upshot is that Wintertrace and Schneespur now update themselves. No FTP, no overwriting files by hand for a routine release.
Why modules
Jenni can also serve modules — and that part arrived faster than I expected.
Julian is happy with a plain installation that does the basics. But other operations have staff, run longer routes, and need more: shift handling, maintenance records, reports, and so on. Putting all of that into one application makes it cluttered for the person who only wanted to log a morning’s work.
The software is meant to be for everyone. So instead of one heavy app, the plan is a lean core that modules extend. The first one already exists: a diagnostic module that lets operators send me error reports without much fuss — which, of course, needed yet another small service built to receive them.
The longer-term idea is a core solid enough that modules can extend almost any part of it. The candidates being worked through include notifications, additional weather providers, employee management, reports, audits, country-specific rules, app (PWA) customisation, and exports. To be clear: most of those are planned, not finished. The diagnostic module is the one you can actually use today.
So who am I — and am I in winter service?
The second question is easier, so I’ll take it first: no, I’m not in winter service. I’ve never run a plough.
My name is Michael. I’m 37, born in Passau in Bavaria, trained as a chef, and I’ve spent the last eight-plus years driving trucks. Programming, websites, and the web in general are things I’ve been involved with for a long time on the side. For about the last year I’ve been working intensely with AI — everything from a blog written through an AI character to vibe-coding WordPress plugins and small services like this one.
So Wintertrace comes from someone who watches winter service from the outside, building closely with someone — Julian — who does it for real. That’s also why the feedback button matters: the further I am from the cab, the more I need to hear from the people in it.
Who actually writes the code
Here’s the honest version. The author and programmer of Wintertrace is, in a literal sense, Claude Code working through the GSD workflow — not me typing every function.
That doesn’t mean files appear one after another with no oversight. The work is structured: the project is fifteen milestones in, each milestone made of five or six slices, each slice of four to seven tasks. Around that sit research and tests. And I’m in the loop the whole way — I review what’s produced, argue with the AI about its choices, run the live version myself, and have found plenty of bugs it didn’t catch on its own.
One thing worth being precise about: this is software built with AI, not AI software. Wintertrace is ordinary PHP and MySQL. It doesn’t run a model, it doesn’t make predictions, and it doesn’t send your data anywhere clever. The AI is how it gets written, not what it does.
The one-file installer
A small extra service joined the set recently: a single-file installer.
Plenty of winter service operators aren’t especially technical, and asking them to upload roughly 16 MB across hundreds of files over FTP is slow and easy to get wrong. Instead, you upload one file through your hosting’s file manager or WebFTP, and that file downloads the current version for you. It’s simply faster, and it fails less often.
Who it’s for
Wintertrace is built for the everyday winter service operator — the one-truck contractor, the small team, the property maintenance business with a handful of drivers.
In scope and capability it works for larger firms with staff too. But bigger operations usually have different demands and need more on top — which is exactly what the modules are for.
Where it is now
Version 1.0.5 is online today. The next release, 1.1.0, is a few days out: some bug fixes, plus a substantial opening-up and preparation of the module system. After that, more modules should follow, so the diagnostic module isn’t on its own for long.
The principle stays the same. The core is for everyone. If you want more, that’s what modules are for.
Why free, why open source
All of this is open source and free to use. Why?
Because I enjoy it. The honest framing is that this is a hobby that got out of hand in a good way. Funding might come later, depending on demand and interest — managed hosting for people who’d rather not self-host, paid modules, an installation service, or commissioned work. But the core is meant to stay usable and free.
If you want to see what’s been built, the source is on GitHub, the auto-update mechanism has its own feature page, and you can follow what’s planned on the roadmap. The about page lays out the project’s scope and operating principles in short form. And if you run winter service yourself, the feedback form goes straight to me — that’s still the fastest way to shape what gets built next.