Why the software stays small — and why its biggest module is a warehouse

The Warehouse module has shipped. In one breath: it keeps stock for a winter service — de-icing salt, grit, shovels, gloves — inside the software that already documents the work, so “what is where, and who used what for which customer?” has an answer instead of a shrug.

It is also the largest single thing I have built for this project so far. Which makes it a decent moment to explain the software underneath it, because the two facts belong together. The module is big precisely because the program it plugs into is meant to stay small.

The software is meant to stay small

Wintertrace is a documentation aid for a winter service. That is the whole ambition of the core: record the work, capture where and when and in what conditions, and produce a record you can hand over afterwards. It is not an all-in-one suite for running a business, and it is not trying to grow into one.

That is not modesty. It is an observation about the people who install it.

An operator who has been going a few years already owns software. Invoicing runs somewhere — an accounting package, a bookkeeper’s portal, a folder of spreadsheets that works well enough. Contracts might sit in a system somebody in the office knows inside out. Stock might already be handled by a proper inventory program, because the business does more than winter service and always has.

A program that insists on owning all of that does one of two unpleasant things. It duplicates what you already have, so now there are two places where the truth is kept and neither is trustworthy. Or it forces a migration nobody asked for, which is a fortnight of work handed to you by a piece of software you installed to save time.

There is a smaller version of the same problem too. My colleague Julian, the one this whole thing started as a favour for, wants to log a morning’s ploughing and go to bed. Every feature I add for a ten-truck operation is a screen he has to walk past.

Which is what the modules are for

So the core stays lean, and modules extend it. A module adds exactly what it says on the tin, and nothing else.

Nothing is installed by default. You look at the module list, install the one thing you are missing, and leave the rest alone. If you don’t want notifications going out over Telegram, you don’t get a Telegram configuration page you have to ignore forever. If you already run inventory software, Warehouse is a line on a list you never click.

That sounds obvious written down. In practice it is the decision that most shapes what this software is, and it is the reason I can build something as large as this module without making the everyday installation worse for anyone.

The biggest one so far, and a different shape

Some numbers, because “big” on its own is a sales word.

Packaged, Warehouse is 380 KB: 101 PHP files, 11,665 lines of PHP, and 19 database migrations. The previous largest module, Documents, is 307 KB — 67 files, 8,656 lines, 10 migrations. So Warehouse is the biggest module so far on every measure I can count, not just on a feeling I had while building it.

But there is a difference in shape that the file counts hide, and it matters more than the size.

Documents was three building sites for one module. There was the module itself, there was NoSign — the signing engine I ended up writing from scratch because nothing existing did what I needed — and there was the API in the middle that keeps the two apart. Three pieces of software, each roughly the size of the others, to deliver one entry in the module list.

Warehouse is one unit. Everything it does happens inside the module, on your own installation: no external service, no registration, no account to sign up for. It is bigger than Documents and, structurally, considerably simpler. The whole of it went into the one place where it belongs.

It was built for one purpose: to help a winter service operator with stocktake, with the administration around it, and with keeping sight of what is where and who used what for which customer.

What it takes off your plate

The module page walks through the screens. Here are the five things that actually change the day.

Stock is a ledger, not a counter. Every delivery, transfer, consumption, issue and return is a separate booking, and the stock figure is the sum of all of them. Nobody maintains a number. Nothing is deleted either — a mis-booking is reversed, and both lines stay visible. That means a figure you find surprising can be traced back to the movements that produced it, which is the one thing a spreadsheet does not do for you.

Every vehicle and every driver is its own location. The main warehouse, each truck, each driver, each with its own stock. Items are yours to define, one unit per item; the module never converts between units, because an operation that thinks in bags should keep thinking in bags.

Drivers book what they used, in the app, during the job. Material comes off that vehicle’s stock, not a pooled total. There are “last time” shortcuts that repeat the quantity last used on that truck, and a readout showing what remains before anything is booked. No slip of paper, no catching up the next morning.

Reordering happens before the pallet is empty. A low-stock threshold per item feeds a reorder list grouped by supplier, with the last purchase price and a suggested quantity. One action emails a supplier every outstanding line at once.

Material cost stops being an estimate. Valuation is weighted average cost — the usual method for bulk material, where a new delivery mixes into what was left of the old heap. Out of that come material cost per job, per customer and per period. One optional setting, off by default, puts a single net material-cost total on the job report your customer receives — never a price per item.

Around those five sit the things you need a few times a season rather than daily: stock value in total and per category, expandable down to the item; a guided stocktake that books all counted differences in one pass and leaves a difference report; a season assistant for the start and the end of the winter; CSV and PDF export, which is usually the form a bookkeeper asks for. Equipment runs through the same mechanics with a different ending — issue to a driver, return, write-off, and an overview of who has held what since when, with drivers returning their own kit in the app. Ten individually assignable rights decide who in the office may do which parts of it.

One plain limitation while I am here: amounts are currently shown in euros, and there is no currency setting yet. Further currencies and additional weight units are recorded on the roadmap.

4.19 billion tokens

The honest build note, since I have never hidden this part.

Wintertrace is vibe coded with Claude Code — I steer, review, argue with it and run the result, but I am not typing every function. In the Documents post I wrote that it had cost “a quantity of tokens I’d rather not total up”, and pointed at riptokens.com, which shows what that sort of build actually consumes.

This time I totalled it. 4.19 billion tokens went into this one module. That is my own figure, off my own meter, and the site’s name reads to me like an epitaph: rest in peace.

Worth repeating the distinction that post set, because it is easy to blur. This is software built with AI, not AI software. The Warehouse module is ordinary PHP and MySQL running on your hosting. No model runs inside it, nothing is predicted, and your stock levels are not sent anywhere clever to be thought about. The AI is how the code got written, not what the code does.

I am neither boasting about that nor apologising for it. It is simply how a single person gets 11,665 lines of stock keeping written and tested in the time available.

If your stock still lives in a spreadsheet

Then this is for you, and it costs nothing. The module is free and open source like the rest of it: install it and it is there, with your existing customers, jobs, vehicles and drivers already in place. You can start with a recorded opening balance on the day you install and let the ledger take it from there.

And the other half, which matters just as much: if you already run inventory software that works, do not install this module. That is the entire point of doing it as a module. Keep the system your business already knows, and let Wintertrace get on with documenting the work.

Where it stands

Warehouse needs Wintertrace 1.0.0 or newer. Alerts arrive by email, or over Telegram if you have the Telegram module installed.

If you want the detail, the Warehouse module has its own page with the screens on it, the other modules are on the module list, and what comes next is on the roadmap. The feedback form still goes straight to me — and for a module like this one, where I am guessing at how a real depot counts its salt, that is the fastest way to tell me what I got wrong.