Schneespur
A five-minute conversation. Then it escalated.
The problem
If someone slips on a pavement that wasn't cleared, the operator is liable — unless they can prove it was cleared and gritted, at that time, at that address. A note on a slip of paper rarely holds up. And the software that exists is either a pricey monthly subscription, looks like 2009, or is built for enterprises — not for someone doing winter service on the side to earn a few euros.
Who had it
My colleague Julian. We were chatting about vibe coding at work; I asked "need anything?", he said "sure". He does winter service in the winter — shovelling, clearing paths — and in Germany you'd better document that. That was the whole briefing. Five minutes.
"So I said… sure, I can do that for you. Sounds like an interesting use case — and a few hours later the whole thing had already escalated. As it tends to with me." — from the blog post on how Schneespur started
How it got built
This is where the hobby changed gear. Up to then it had been n8n workflows and WordPress plugins. Schneespur needed a proper application — Laravel with PostgreSQL, GPS tracks, weather snapshots at the start and end of every job, up to five photos, a PDF proof-of-service generated the moment the driver taps "finish", a driver PWA that works offline in a cab, a customer portal. I'm not a trained programmer; alone this would have taken years or never happened.
So I built it the way the ./how page describes: Claude Code as the agent, GSD as the discipline — every feature discussed and planned before code, executed in small plans, verified by me on a real installation. Decisions I'd make again: drivers use the OwnTracks app instead of a custom one (no app store, nothing to maintain). It runs on a plain shared-hosting package, because that's what a small business already has. And the core stays deliberately small — GPS, weather, photos, PDF. Everything else (warehouse, contracts, Telegram, tours) is a module you can leave out. That's also how one codebase can be Schneespur in Germany and Wintertrace everywhere else — the name and the legal bits switch with the language.
And then the question nobody asks a hobby project but everyone should: who checks the AI's code? I answered it with two penetration tests — run by a different AI agent (Strix, on a model from another family, on purpose), one white-box against the source, one black-box against a live throwaway demo. Seven findings, two of them serious, all fixed in the next release with a regression test each. The full write-up is public on the Schneespur blog. I'd rather publish that than pretend.
- from "need anything?" to a running app: a few weeks, spring 2026
- ships as Schneespur (DE), Wintertrace (intl) and schneespur.cz — one codebase
- installer is one file: upload, open in browser, done in ~10 minutes
- signed (Ed25519) one-click auto-updates via Jenni
- 2 AI penetration tests · 7 findings · all fixed, each with a regression test
- 48-hour throwaway demos anyone can request
What runs today
Real operators, real winters. A modular core with a growing module directory, a customer portal, and the pentest habit now part of every release. It also pulled the next projects out of the ground — the updates needed Jenni, the contracts needed NoSign.
Jenni
In Forrest Gump, Jenny is the reason Forrest runs. Jenni is the reason my updates verify.
The problem
Schneespur is open source: no registration, no phone-home, download it and it's yours. So how does an operator I've never heard of get the next version? Every install out there needs updates. Every WordPress plugin needs a stable update endpoint, a verifiable hash, a virus scan someone can point to. I was already self-hosting downloads — badly: zip the build, drop it in a folder, link it. GitHub is where I show code, not where production should fetch its next version from.
Who had it
Me. Purely me. This is the least glamorous project on the page and the one I use the most.
How it got built
"I asked Claude to build me a download server." That sentence makes developers wince — they picture unreviewed AI output pasted into production. Jenni was the opposite: the project where I set out to prove the responsible version of this to myself. Because it's infrastructure. It runs on other people's stacks and ships files to third parties.
So the build was slow where it mattered. Every problem arrived one at a time and got its own GSD phase: first plain versioned downloads and an update API. Then a JSON catalog, because Schneespur wanted a module directory without me running a marketplace. Then the uncomfortable one: my auto-updater trusted TLS for everything — a breached server could push anything to every client by morning. So Jenni learned to sign every release with Ed25519, with a root key that lives on my laptop and never on the server. Then an author API, so module authors can submit their own uploads through the same scan-and-sign pipeline.
I read every line of the upload pipeline. Magic-byte sniffing, zip-slip protection, zip-bomb caps, ClamAV on every upload, Argon2id, rate-limited login, TOTP-2FA, non-root container. Then she ran against my own production for months before she got a website. The code is fast. The trust is slow.
- one binary: downloads · update API · Ed25519 trust layer · wp.org deploy · module catalog · author API
- root signing key kept offline — a breached server can lie, it cannot impersonate
- ships every BreznFlow release and every Schneespur update · zero incidents
- the download widgets on ./projects are served live by her
What runs today
jenni.noschmarrn.dev — my "staging but actually production" instance. The most-used and least-talked-about thing in my stack. A public repo and a setup wizard are what's left before she goes public.
NoSign
«No Schmarrn. Just Signatures.»
The problem
Schneespur got a module that lets operators draft service contracts for their customers inside the app — pick customer and site, take a template or write your own, done. The missing piece was the signature. The usual dance — print, post or meet, sign, post back, scan, file — is slow and joyless. Customers should just sign. In seconds. On their phone.
Who had it
Schneespur's operators — and, it turns out, anyone who has ever gone looking for an open-source e-signature tool. I tried the existing ones; they're good. But depending on the tool, the feature I needed either didn't exist or sat in the paid tier: one had everything, but the API was a paid add-on on an app that calls itself open source. Another was solid but had no real hard delete — and I don't want to hoard other people's contracts.
How it got built
Rather than get burned by a fourth tool, I built the one I wanted. It was never planned — it was supposed to be a small signing helper inside a Schneespur module, and it escalated into its own project within weeks. The scope decision came first and was the important one: NoSign is a signing motor, not a vault. Your backend posts a PDF and a signer list; NoSign runs the ceremony (email verification, view the PDF, consent captured verbatim, draw, submit), seals the result as PAdES-B-T with an RFC 3161 timestamp from a self-hosted TSA, delivers it by HMAC-signed webhook — and on your acknowledgement, hard-deletes everything. Only a PII-scrubbed tombstone remains. What it deliberately isn't: a qualified signature. No video-ID, no NFC passport check. A simple electronic signature with a strong audit trail — which is exactly what a winter-service contract needs.
This one shows what the agent workflow is good at: the standards are dense (PAdES, RFC 3161, CMS signatures), and an agent that can read specs, write the implementation and test it against real PDF validators is a massive shortcut. What it's not good at is deciding what the product is. That's the "motor, not vault" call, the "every feature is free" call, the "delete on delivery" call — all mine, all written down before code.
- started as a contracts module inside Schneespur — grew into its own project
- sequential multi-signer · five field types · reusable templates · decline & expiry with reminders
- full REST API and hard delete are free — not a paid tier
- public offline verification of the sealed PDF
What runs today
The Schneespur/Wintertrace contracts module has been live since June 2026 and signs through my hosted instance at nosign.app; the standalone open-source project lives at nosign.dev for anyone with the same itch.
Donau2Space
Where all of this started. A TikTok video about n8n.
The problem
None, honestly. Just a question: can you fully automate a blog with n8n — and how far does it go? That question became Mika Stern, a fictional 18-year-old maker from Passau, building an amateur rocketry project along the Danube and blogging about it every day.
Who had it
Me, on the sofa, after a TikTok video. "Just play around with it for a bit." Famous last words.
How it got built
This one predates Claude Code in my workflow — it's the n8n era. 78 workflows, designed by hand, one at a time: daily articles, generated images, podcast narration via ElevenLabs, forum posts, newsletter, social media. The part I'm proudest of is the memory: Mika has a MySQL long-term memory (89 tables), so every day is a continuation of the last, and reader comments are fed back into what he writes next. Readers can nudge the story. And every AI job is logged to a public "AI black box" page, because I'd rather show the machine than hide it.
It's also where I learned the two rules everything since has followed. One: the AI doesn't have the ideas — it executes them. The workflows didn't write themselves. Two, learned the expensive way: watch your automations. In spring 2026 a workflow with broken YouTube credentials never completed and quietly re-asked OpenAI every few minutes — for over a month. The black box page had shown it the whole time; I just hadn't looked. My fault, fully, and I wrote it up as such. Monitoring and automatic stops for failing workflows have been non-negotiable in everything since.
Side effects: I kept needing WordPress plugins that didn't exist the way I wanted — that's where BreznGEO (SEO/GEO with AI meta descriptions, llms.txt, Schema.org) and BreznFlow (interactive n8n diagrams in posts) come from. Both free on WordPress.org.
- 78 n8n workflows · ~99 % automated end to end
- 252 articles · 252 podcast episodes · ≈ €1.21 per article, all-in
- MySQL long-term memory · reader comments feed back into the story
- spawned two WordPress plugins and three sibling character blogs
What runs today
Paused and being rebuilt — the engine is getting the agent treatment. The knowledge base stays up as the making-of of the making-of.
Rastplatz.app
The one I'd have wanted at the end of every shift.
The problem
Germany — Europe, really — is short tens of thousands of truck parking spaces. Every driver knows the feeling: driving time is running out, the next three rest areas are full, and the choice is between a fine and a ditch. Official occupancy data exists for some rest areas, but it lives in places no driver looks at 9pm. I won't fix the shortage. But I can put a hand under it.
Who had it
Me, for 8+ hours a day, and every colleague I've ever talked to. This is the project with the most "wouldn't it be nice if" behind it — collected over years in a cab.
How it got built
The first thought was just "a map that shows where I might still find a spot". Then — as with Schneespur — it escalated. The rule for this one: whatever can be done without external services gets done without them. No Google Maps. Rastplatz.app serves its own OpenStreetMap map: a dedicated build server pulls the fresh raw data every night, checks whether anything changed, and renders the tiles — plus a truck layer with height, weight and length limits and ADR (dangerous goods) restrictions on motorways and tunnels. A map a driver can use even without the parking part.
Every rest area gets an aerial photo — automatically, from each federal state's public imagery, with a small algorithm that picks the right zoom from the motorway exit, the service station and the number of spaces. Weather comes from a self-hosted BrightSky instance (German Weather Service data) with a 48-hour forecast per spot. And under all of it: live reports from drivers — "all full", "three left" — because the official number of spaces and what drivers actually do are two different things. Next up: routing via a self-hosted Valhalla server. Not navigation — more "I'm in Passau, it's 4pm, I've got four hours left and need to reach Berlin: where do I get a spot?"
Same workflow as everything else here. Claude Code builds the pipelines; the research, the "do we need this?" and the server planning are mine — I do this with six servers now, and I refuse to reach ten. It runs in my own truck first.
- own OpenStreetMap tiles, rebuilt nightly · truck & ADR overlays
- automatic aerial photos per rest area from public state imagery
- official occupancy data + live driver reports · secret spots, private by default
- free · ad-free · no external map or weather APIs · DE + EN
- future flagship — ships when done
What runs today
An early version at rastplatz.app: the map, the rest-area pages, the aerial photos. No real design yet — the plumbing comes first, the paint later. In active development.
Every one of these started with one person's problem — or one five-minute conversation. If you've got one: let's talk — ideally we build it open source, so the next person with the same problem gets it for free.
→ Got an idea?