Thirty minutes after I had the idea, I was opening a bills dashboard on my phone. It reads our bills from my own Gmail and runs on the Raspberry Pi at home. I wrote no code and read none, which makes it my first fully vibe-coded project.
This is the whole 30 minutes, what broke, what the data said, and where I would stop doing this.
Why I vibe coded a personal project
A while ago I saw a Facebook post claiming that we now pay a few times more for electricity. It sounded wrong to me, but I realised I could not actually prove it: I had never paid much attention to what exactly we pay each month for electricity, water and heating. The bills arrive in my Gmail as PDFs, and I had never put a year of them side by side.
That made it a good candidate for something quick: small, personal, and checkable against bills I already have. So I asked Codex for a dashboard, and this is what it showed me.
Our electricity bills are not several times higher. For the same nine months, January to September, we paid €351.73 this year against €315.85 last year: about 11% more. Almost all of that is the last two bills. January to July is within 2% of last year, and August and September together cost €32 more (€103.23 against €71.21). This is one household, not a national statistic, but it is exactly the claim as it was put to me: what we pay.
To see why, I opened the August invoices for both years. Both totals match the dashboard to the cent.
| August 2025 | August 2026 | |
|---|---|---|
| Consumption | 236 kWh | 340 kWh |
| Day energy price | €0.0895 per kWh | €0.0930 per kWh |
| Night energy price | €0.0386 per kWh | €0.0410 per kWh |
| Total | €32.82 | €49.51 |
(The 2025 invoice is in leva, so I converted its prices at the fixed rate of 1.95583.) We used 44% more electricity, while the price per kWh moved by roughly 4% to 6%. So the bump is mostly usage, not a price explosion, and it appears only in the last two months. Other posts blamed the war in Ukraine or the switch to the euro in January. A rise that starts in August fits neither story.
One thing to read carefully in that screenshot: the green card says we are down 21% on last year. That is only because the year is not over yet, as it sets nine months of 2026 against all twelve months of 2025. The monthly average card (+5%) has the same problem and understates the rise.
The prompt, and what Codex asked back
I used Codex (OpenAI's coding agent) with GPT-6.1 sol. This was the entire prompt:
We need to create an app/dashboard to track our water, heating and electricity
bills. They arrive as PDF files in my email. Requirements:
- no need for authentication, it will run on my home Raspberry Pi
- only one page with 3 checkboxes, one for each bill, so I can turn each one
on or off separately
- the main goal is visibility over time: I want to see what I am paying each month
- I will leave it to you to decide whether to listen for a specific email
(by sender) or scan every day
- I will also leave it to you how and where to keep the data (might use
Firebase, some other cloud solution or even a local database)
Any questions?
The only things I decided were the shape (one page, three checkboxes), the goal (visibility over time) and the setting (no login, my Pi at home). Storage and how to find the emails I handed over on purpose.
Codex came back with four questions:
- Which email provider, and do all three bills arrive in the same inbox?
- Can you attach one example PDF per utility and the sender address?
- Should the first import include all past bills, or start from a particular month?
- What counts as "paying each month": the amount billed, or actual payments?
I answered, sent the sender addresses and some example invoices, and that was pretty much the whole conversation.
The 30 minutes, in order
| Step | Time |
|---|---|
| Initial build with Codex | ~15 min |
| Tweaks | ~5 min |
| UI polish with Claude Design | ~5 min |
| Clone, run and install on the Raspberry Pi with Hermes | ~5 min |
| Total | ~30 min |
What broke: missing invoices. Senders had changed their email addresses over time, and some invoices have a different layout, so the first version was missing bills. Most of the tweak minutes went there.
How I checked it. I compared five or six bills by hand with what the dashboard showed, and they were correct. That is all the verification I did. Hand-checking a few bills is the weakest kind of evaluation, and I wrote about doing it more systematically. Codex's own notes say the parsers were validated against only seven sample PDFs, and anything they cannot read confidently lands in a "second look" queue instead of being guessed.
The design polish was optional. I used Claude Design (Anthropic's design tool) for five minutes of polish, mostly out of curiosity. The dashboard did not need it.
The last five minutes. Hermes, an open-source agent from Nous Research that runs on your own machine, copied the project from my PC to the Raspberry Pi, built it, ran it, made it installable as a PWA and handled the TLS certificate that makes installing it on a phone possible.
What Codex built while I was not looking
It is more than I asked for. The prompt said nothing about any of this, and this is Codex's own summary, which I did not verify:
- a Python and FastAPI backend of about 750 lines, with SQLite storage and the original PDFs kept on disk
- local PDF parsing with per-provider rules: no OCR, no AI
- a daily Gmail check, plus a review queue for bills it cannot read confidently
- amounts stored as integer cents, with older leva bills converted once at the fixed rate (Bulgaria moved from the lev to the euro at the start of this year)
- tests for the parser, the storage and the PWA, and a hardened Docker setup for the Pi
Codex made all of those decisions, not me.
Out of curiosity, I checked the token usage of the whole Codex chat: about 50.4 million input tokens, around 97% of them cached re-reads of the conversation, and about 241 thousand output tokens including reasoning. The chat kept going after the app was ready, so these numbers cover more than the 30 minutes.
What I did not do
I read no code. The term "vibe coding" was coined by Andrej Karpathy, and Simon Willison defines it as building software with an LLM without reviewing the code it writes. By that definition this is the real thing.
That is the difference from Tiny Greenhouse. There I wrote no code either, but I read it and understood it, and every change went through a plan, spec, implement and verify loop. Here it was one prompt, a few follow-ups and trust.
What I did do: I discussed the parts that worried me most, the Gmail integration and the PDF parsing, with Codex, and I checked the output against real bills.
Three "yes, but" objections
"There is already an app for that." Probably. But I would have to find it, register, watch ads or pay a subscription, and hand it access to my data. Here I prefer the local, safe and free option.
"It is just a dashboard." It saves me from digging through a year of emails and comparing PDFs by hand, and it answered a question I could not have answered by feel. Building something like this, and much more complex things, from a few human sentences still amazes me.
"You gave it access to your Gmail and you do not know how it works." Fair, and this is the objection that matters. What limits the damage is the audience and the stakes, not my verification: the app is reachable only on my home network, it is used by me and my wife, it holds bills we already own, and nothing in it is critical. I discussed the key parts with Codex, which is not the same as checking them, and I know it.
Where my line is
Anything used by other people, with authentication and stored user data, is not something I would vibe code. Utilify is personal: me, my wife, a local network, bills we already own. Martin Fowler makes a similar point, that vibe coding is best used for disposable software used by its author or a small group who understand and accept the risks.
When the work has to be right, I go the other way: tickets, specs and review, the ticket-per-agent style of managing AI agents like a team. This project sits at the opposite end of that spectrum.
What I take from this
I did not build something unbelievable, but I built something useful with very little effort, and it was fun. What stays with me is how easy it has become to turn an idea into a working app: a doubt about a Facebook post became a dashboard on my phone in 30 minutes. It also showed me where I am comfortable with this approach and where I am not, which is probably the more useful thing to know.
If you want to vibe code something, or build it the "old" way, with proper engineering, tests and review, don't hesitate to contact me.
