The Bill, Itemised

I want to tell you what this site cost to build, because I think the numbers say something, and because a record that asks you to trust nothing it cannot show you should not be shy about its own workings. This is the third of four posts on how the site was built; the first two were about what it refuses to publish and how it holds up when a crowd arrives.

There are two numbers. What I paid was two ordinary monthly subscriptions, one per account, at US$200 each: US$400 for the month that covered the build. What the same work would have cost billed by the piece, token by token, at the model maker's published rate, is between US$2 800 and US$3 300, roughly R50 000 to R60 000.

The second number is the one worth looking at. It is the size of the work: not servers, not a salary, but the model's effort at helping write the software, over about a week at the end of September and the start of October.

What got built

A record like this is not one thing. It is a store of every woman found dead across Ekurhuleni since July, one row at a time, in the order the bodies were found. It is the machinery that reads around thirty-five news outlets and the government's own statements every two hours, pulls out what each one claims, keeps the sentence and the link behind every value, and marks the places where two outlets disagree instead of quietly picking one. It is the pages that show you all of that, and the connection that lets an AI assistant read the record directly so you can ask it questions and check its answers against the sources.

Counted in the plainest way, that is about twenty-eight thousand lines of code and another twelve thousand lines of tests, plus the written rules for how the record decides what it may and may not publish. It was built in about a week.

I could not have done it in a week before. Not close. Work of this size, done properly, with the checks a record about dead women has to have, is months of one person's full-time effort, and more likely the better part of a year. The tools did not make a good record; people and sources do that. They made a good record reachable for someone with time and care but no funding.

How the cost is counted

Every time the model does a piece of work, it reports how many tokens it read and wrote. A token is a chunk of text, a few letters on average. I added up every one of those reports across the whole build, on both accounts, and priced each kind of token at the published rate for the frontier model that did most of the work: US$10 per million tokens read fresh, US$50 per million written, 25 US cents per million re-read from the cache, and US$12.50 to US$20 per million stored in it. That gives the US$2 800 to US$3 300. I did not pay that per token; the work ran on the two flat subscriptions. It is what the usage would have metered without them, and the fairest way to show the size of the job.

The spread is the one uncertainty. Text stored in the cache is billed at one rate if it is kept for five minutes and a higher one if it is kept for an hour, and the usage reports do not say which. The true figure sits inside the band.

The bill splits roughly into thirds. The writing, the tokens the model produces, comes to about US$1 000. Storing the growing codebase in the cache, so it can be re-read cheaply, comes to US$850 to US$1 370, and that is the line that carries the uncertainty. Re-reading it, which the model does on every step, comes to nearly as much again. Each of those tokens costs a fortieth of a fresh one, but there were close to four billion of them, and even cheap things add up at that volume. Fresh input that was not already cached is a rounding error.

Two more notes. The figure counts the whole build window, both accounts, no days missing, but it leaves out the work that went into this post, which is not building the site. And it is not the running cost: keeping the record current, the reading-the-news job, costs its own smaller amount every week.

What the money bought

A number on a screen is worth nothing if the code under it is quietly wrong. So the record was built with tests alongside it, small programs that check it still does what it should, and they grew with it, from a few dozen on the first day to a little over eight hundred by the end. The rules the record keeps, names only as published, no suspect named, no home address, no deaths called a series unless an official does, are written as tests too, and the ones that could do the most harm stop the pipeline from publishing.

The same week bought more than tested code. It bought a site that stays quick when a crowd arrives all at once, checked by machine every time its code changes, and probed by an AI security tool against a throwaway copy, with a person reading every finding. Those are the first two posts in this series. Here it is enough to say the money did not stop at writing the software.

Why spend it here

Because the alternative was nothing. Before these tools, a sourced, cross-checked, machine-readable record of a case like this was the work of a newsroom or a research unit, not a volunteer. The gap between what one person could do and what the story needed is why so much of what circulates about these women is wrong: a count that keeps moving, a suburb that jumps fourteen kilometres because two reports folded two women into one paragraph, a "serial killer" said as fact that no official has confirmed. The tools closed that gap enough for one person to keep a record that does not do those things.

They did not make it true. That has to be said plainly, because it is the easiest thing to get wrong about this kind of work. The money bought help writing software. It did not buy a single fact. Every fact on this site still rests on a named source and a quote you can open yourself, and where the sources disagree the site still refuses to choose for you. The spend bought reach, not authority. If an answer here is ever wrong, it is wrong because a source was wrong or I made a mistake, and both of those are things you can catch, not things a budget papers over.

The shape of the week

The two tall days did most of it. The first day was the first machinery and the first tests. The first of October was the heaviest, a hundred changes, most of them safety: the rules that lock down what the pages may load, a published way to report a security hole, a written plan for when something goes wrong. The third was a rebuild that pushed the website's tests past three hundred. The quiet days in between were for fixing and checking, which is most of the real work, and by the fifth it was being readied to be seen.

If you want to see what it bought, the record is here, and every line on it shows its working: kempton.watch/sources

— Piet

---

Showing the Working — how this site was built: What This Site Refuses to Publish · Built for the Worst Day · The Bill, Itemised · Don't Trust Me. Check the Record.