
Meta article · July 2026
This is a meta article: documentation of what actually happened. Not the polished version — the real sequence, including the decisions, the dead ends, and the bugs that surfaced along the way. Anyone who wants to walk the same path should be able to follow it.
The assignment
The problem. My projects lived in six places: Basecamp for team assignments, Google Drive for files and invoice drafts, Descript for video editing, Gmail for everything that was ever agreed, a Google Sheet for the content library, and the rest in my head. When Dennis asked where something stood, I had to open three tabs. Every week I assembled my invoice by hand from whatever I could remember finishing.
The goal. One place that shows me where I actually am. With invoicing built in, because invoicing is where disorganization turns into lost money.
The source material. My Gmail inbox, Google Calendar, Google Drive, Descript, and Zoom — all connected to Claude. No briefing document, no prep work. That was the test: can an agent build a working system out of what is already lying around?
The process
Step 1: Ask before building
Claude did not start building. It asked four things first: How should this save? How do you bill? What do you want to see per project? Where should it run?
That sounds trivial. It is the reason the result is usable. On billing, I answered that I have fixed prices for podcasts — one euro per raw minute, for instance — but also articles and revenue shares. Without that question I would have gotten an hourly-rate tool I could not use.
Step 2: Read the actual data
Claude worked through Gmail, Calendar, Drive, and Descript, and reconstructed reality from them: eight clients, thirteen live projects derived from Basecamp threads and mail chains, fourteen open tasks with real deadlines, and my billing model pulled out of an invoice draft sitting in Drive — one euro per raw minute, ten euros per article, effort sizes Small, Medium and Large at twenty, forty and one hundred dollars, small-business tax status, fourteen-day terms, invoice numbers in the format LP-YEAR-NNN.
The interesting part was not the volume. It was what became visible. Four items in my weekly overview were flagged “not Leo” — disputed attributions I had never discussed with anyone. A payment had been outstanding for days. A client had been waiting two days for a reply. All of it sat in the open in my own data, and I had not seen it, because it was spread across six places.
Step 3: Build
The result is a single HTML file. No server, no account, no cloud. It sits on my machine, I open it in a browser, the data stays in the browser. Plus an export to a backup file.
Why a file and not a web app? Because I own it. No subscription that lapses, no vendor that shuts down, no question about who holds my client data. The cost: the data is tied to one browser on one machine. Hence the export — without it, this approach would be reckless.
The data model covers ten areas: clients, projects, tasks, Claude projects, time entries, invoices, expenses, ideas, appointments, and delegated jobs. Eleven views, including a daily cockpit, a weekly view, drag-and-drop project boards, time tracking with a timer, and a finance overview with tax reserve.
Step 4: The part that actually saves time
Weekly invoicing. It takes everything that is finished and not yet invoiced, bundles the raw minutes into one line item, articles into a second, effort sizes individually, converts dollar amounts to euros at the stored rate, assigns the next free invoice number, and marks the billed items as done. One click.
That used to be half an hour of manual work each week, during which I regularly missed something.

The decisions worth discussing
Round line items to cents before summing. Testing surfaced this: three effort sizes at one hundred, forty and forty dollars came out at 87.72, 35.09 and 35.09 euros at a 1.14 rate. Added up, that is 157.90 euros. But the app was summing the unrounded values internally and arriving at 157.89. One cent — on an invoice where the line items are visible, that is the kind of error an accountant spots and that costs trust. Now every line rounds to cents before the total is computed.
Bundle raw minutes instead of listing them separately. An invoice line reading “Editing and post: 47.5 raw minutes” reads better than twelve lines at 3.9 minutes each. The individual entries stay in the app; the invoice shows them aggregated.
Progress is computed from tasks. As long as a project has tasks, the percentage bar cannot be typed in. A self-assigned progress number is a claim. Checked-off tasks are a fact.
A required “next step”. Every Claude project has a next-step field. The app shows a warning when projects are in flight with that field empty. Those are exactly the ones that stall — not because they are hard, but because it is unclear where to start.
Tested, not assumed
Before handover, automated runs executed in a simulated browser: the app loads, projects get created, line items typed, invoices generated, printed, statuses cycled, the app restarted. 138 checks across three build stages.
Three real bugs surfaced. The cent discrepancy between line items and invoice total described above. An unguarded reference to an input field that no longer existed, which crashed the search bar if you closed it quickly. And a yes/no field stored as text instead of a boolean, which meant it did not survive a restart.
All three would have hit me in daily use. The third would have lost data silently.
What came after
A delegation channel. I can hand any task or project to Claude. One click generates a full briefing — not just my one-liner, but automatically my billing model, the related project with its description and open items, the client with contact details and background, the deadlines. I do not have to explain anything the system already knows. What comes back is a data block the app reads straight back in.
A morning run. Weekdays at 7:30, the inbox, calendar and deadlines get reviewed, open jobs worked through, mail drafts created, and a status report filed. Drafts, to be clear — nothing sends without me.
A live cockpit. A page that pulls calendar, inbox and running automations fresh every time it opens.
The outcome
One file, roughly 4,600 lines, no dependencies beyond a browser. Populated with thirteen real projects, eight clients, fourteen tasks, twelve Claude projects and two invoices — all from data that already existed.
What I did not know and can now see: two automations were running for me that I had forgotten about. One of them builds an invoice draft every Friday — which is exactly what the new weekly invoicing does. Duplicated work nobody would have noticed if both had not ended up on the same page.
That is the real value of an overview. Not the managing. The becoming-visible.
For the next run
- The questions up front were worth more than any correction afterwards. Start building immediately and you build past the need.
- An agent allowed to read your own data finds things you miss — not because it is smarter, but because it looks at everything at once.
- Automated tests are not optional with generated code. Three bugs in one afternoon, one of them silent data loss.
- You only find duplication in your own system once everything sits in one place.
This article follows the BlitzMetrics meta article method: whoever executes a task documents what was actually done, so the next run can learn from it.
Deutsche Fassung: hier lesen
More: AI Systems & Automation