The question sounds harmless. "What are you working on at the moment?" Until recently, answering it meant opening folders on four different machines, trying to remember whether the prototype on the Raspberry Pi was still running. Sixteen projects today, from ideas still on paper to sites already live, spread across a desktop, a VPS, two Raspberry Pis and a phone. Nowhere to see them together.
HORIZON is the answer to that. A catalogue of my projects, nothing more. But the way it is built taught me more than the result itself, and that is what I want to talk about.
One rule: never keep two copies
The first reflex, when you want a dashboard of your projects, is to make a table. A spreadsheet, a database, a notes page with one row per project. It works for two weeks. Then a status changes somewhere, you update the repository but not the sheet, and you end up with two versions of the truth politely contradicting each other. I know that trap because I have built it several times.
So HORIZON starts from a single rule: never maintain two datasets describing the same projects. They always drift apart. Not "often" — always, because keeping a copy up to date by hand is work nobody keeps doing.
In practice, each project is a Markdown file. Status, host, links, a bilingual summary. That's all. The web catalogue reads those files, and the consolidated summary — the one I read myself when I want an overview — is regenerated on every build. If a piece of information is wrong, I fix the file. Never the copy. The copy doesn't really exist; it is recalculated.
A site you can throw away
That rule has a technical consequence I rather like: it makes the site disposable. Astro produces a static site. No JavaScript framework — just two short inline scripts, one for the project cards and one for the mouse wheel; the carousel itself runs on CSS alone. No remote fonts either, and the screenshots are embedded in the page. The dist/index.html file opens with a double-click, offline, from a USB stick. That sounds trivial until the day you present something from a machine you don't control, on a guest network that filters half the domains. Then it becomes the only thing that matters.
The feature I dropped
The interesting moment of the project was a failure. I wanted to show the API cost per project, month by month. In my head, it was even the feature that justified the tool. I checked: Anthropic's Admin API is not available to individual accounts. The way round it would have been to turn my account into an organisation — for a personal tool, not a step I wanted to take. And no half-measure was acceptable.
I could have hacked something together. Estimate the cost from a hard-coded price, scrape an interface, keep a manual log. Each of those options would have produced a figure shown to two decimal places, with a confidence it hadn't earned. I changed the metric instead. Local session logs give me three things I can rely on: the number of sessions, the last activity, and the token volume. It sells less well than an amount in euros. It is measured.
One detail matters here. Cache reads are left out of the token total. Include them and the figure grows roughly twenty-five-fold, without measuring anything real: re-reading a context that is already cached is not new work. A metric that inflates while activity stays flat is worse than no metric at all, because you end up making decisions on it.
One accent, and only one
On the visual side, I kept to a flat design. One-pixel rules, and no shadows — save one, under the text panel that floats over the screenshots, because a one-pixel rule has nothing to grip on a white capture. And a single warm colour, kept to two cards. That last constraint takes discipline, because the urge to spread an accent is strong when it works: this very week, a third card had turned gold, and I moved it back. An accent stops being one the moment it is everywhere. The catalogue fits on a single page, as a carousel, with a detailed card for each project.
What carries over
Is it useful to anyone but me? No. HORIZON is a personal tool, and I have no intention of turning it into a product. What does carry over is the method, and I would put it like this.
A piece of data is entered once, in one place — the one that holds authority. Everything else is a regenerated deliverable, and can therefore be deleted without loss. And when a constraint is real — or the only way round it costs more than the feature is worth — you drop the feature openly rather than ship an approximate version that gives the illusion of information. I still miss the API cost a little. The session count, at least, I can believe.