A home app for a family with bank accounts in several countries: from a monthly evening with Excel to production in nine days, and two months of daily use since.
I'm Rodion, CTO and co-founder of a software agency. I started as a programmer and can still write code, but in this story that skill barely mattered. In September I built a household finance app for my family working only with AI agents, and two months later my wife and I still use it every day.
This post is about what you can now build for yourself, what it costs, and what I learned doing it. All numbers come from the logs and from git, not from memory. The project is open source: github.com/sars/keepard, with a live demo you can click through without installing anything.
TL;DR
- What: a self-hosted app that pulls transactions from banks in several countries, works out what the family actually spent, classifies it, asks in Telegram when unsure, and tracks all assets in one currency.
- How: nine calendar days, two agent tools (Codex for two days, then Claude Code), about 3–4 hours of my attention a day, 446 prompts with a median length of 26 words.
- Output: 643 commits, ~200 merged PRs, 61 database migrations, 659 tests.
- Cost: ~$2,700 at API token prices, of which 72% was re-reading context and only 13% generated code. Actual cost to me: a $100/month subscription I also use for other things.
- Running cost: ~€10/month for a VPS shared with another project, a $10/month hard budget for the classifier, free open-banking access.
The last straw
Once a month I had a date with Excel: pull together where the money is, how much went out and on what. Accounts in several banks and several countries, my wife's own cards, every bank with its own statement format. I was always one or two weeks late for that date, because the evening it took was easy to fill with something else.
In September the date came around again and I procrastinated again, but this time I thought I'd try it differently. I had wanted for a while to test a serious agentic workflow on something real: not "make me a landing page", but a product with integrations, a database and a deployment that people would actually use afterwards. There was no better excuse.
I didn't even consider off-the-shelf apps, for two reasons. I wanted to build it myself, and the set of integrations a person from Ukraine with foreign accounts needs is specific enough that no aggregator covers it. In the end I got both the experience and a service that costs me almost nothing to run.
Who this is for
- People with accounts in several countries who want to see them in one place.
- Couples who budget together and want the family's spending by category, not just their own.
- Anyone who wants transparency over everything they own, not just spending: accounts, deposits, broker, crypto, in one currency on one chart.
- People who would rather not hand their bank data to someone else's SaaS.
If that's you, the rest is about what it does and how to repeat it.
What it does
Collects transactions by itself. My Ukrainian bank (Monobank) is connected directly through its personal API token; it's the only Ukrainian bank that gives simple access to your own transactions. Foreign banks (Wise, Revolut, a few European banks) are connected through Enable Banking, an open-banking aggregator. Two things I didn't expect: Enable Banking is free for your own accounts, and connecting a bank is just the bank's own consent flow. What didn't work: the other Ukrainian banks. Formally they have open banking; in practice an ordinary person with an ordinary account cannot use it.
Home. Spending this month against the same period last month, day by day. Right: month-to-month analytics, heaviest months highlighted.
Counts personal spending, not everything. Transfers between your own accounts, investments and non-family expenses don't enter the statistics. Refunds are handled correctly too: if a shop returns money, the expense goes down instead of showing up as separate "income". Sounds obvious, but this is exactly where most bank "analytics" break: a transfer to your own other card looks like spending.
Classifies. Rules by merchant and description first, then what the system has already seen, and only then the model. Most transactions land in a category with no human involved. When the system is unsure, it messages me or my wife in Telegram: what was this payment? That turned out to be very convenient. A transfer to someone's card, which two months later in Excel would become "what was that?", gets classified while you still remember.
Review queue. Three payments the system couldn't classify on its own. Right: a payment card with type, category and a slot for the receipt.
Analytics. By category, by period, by each owner, in any currency at the day's rate. There's a "every category, every month" table: rows are months, columns are categories, the darker the cell, the more was spent. You see at once which month went wrong and where. Every number is clickable and leads to the payments behind it.
Where the money went this year. Right: the category-by-month table.
Assets. A separate tab: all accounts, deposits, broker, crypto, cash. One currency, a snapshot every month, a chart. Bank balances arrive on their own, the rest comes from feeds or by hand once a month. Cash lives here too: you can create cash accounts and record cash spending in the app. This is the spreadsheet I used to assemble by hand, now assembling itself.
Assets. Everything in one currency, change over the period. Right: growth over time and the split between invested and not.
The rest. Installs on a phone as a PWA. Has a health page: are the imports alive, when did each bank last update, is any consent about to expire. Makes daily encrypted backups to separate storage. Accepts receipts from Telegram and attaches them to payments. We rarely use receipts and cash. Everything else, daily.
Health page. AI budget ($10 a month, $0.50 buffer), who classified the money this year. Right: bank connections.
Stack, for the record: TypeScript end to end, Node and PostgreSQL on the back, React with Vite, Tailwind and shadcn/ui on the front, Playwright for screenshots and end-to-end checks, Docker on the server. Not because any of it is the best choice, but because the agent proposed it and I had no reason to argue. More on that below.
How it was built
Nine calendar days, 11–19 September. In that time the repository gained 643 commits, around 200 merged pull requests, 61 database migrations and 659 tests. Agents wrote the code; I did terminal commands, configs, registrations with external services, and three to four hours of attention a day. A single prompt of "make me a nice family finance app" and 15 minutes would not have done it.
Two tools took turns. The first two days were OpenAI's Codex, which produced about 4,000 responses in 48 hours and in the same 48 hours ate two weekly subscription limits: once they let me reset the limit, and it ate that too. So from day three I moved to Claude Code, which carried the rest: 10,930 responses over seven days.
Instead of writing code I described an idea, looked at the result, tested on my phone and said what was wrong. The briefs were short: 446 prompts with a median of 26 words, and often I didn't type them at all but dictated them, because that's usually much faster. Three real ones, typos fixed:
"make the pwa feel more like a real app, remove the navbars"
"need to set up backups... want to use aws s3"
"my laptop is very hot and slow... I think it's this project. Why? tests? how to make it lighter"
I know, not very structured and not very programmer-like, but that's how it was.
The third one is my favourite, because it isn't a feature at all, it's a complaint, and it ended in a documented finding: ten parallel git worktrees had put 160,000 files under the macOS indexer, and the laptop was honestly trying to index every node_modules. Now there's a script that excludes them after every install.
Where the money went
The most useful number in those logs isn't about speed, it's about money. Had I paid for tokens at API prices, this build would have cost about $2,700, and 72% of that would not have gone to writing code but to the model re-reading context: the codebase, the documentation, the conversation history. Generated code itself is only 13%.
In other words, in agentic development you mostly pay for context, and most of the practices below exist because I was trying to shrink that bill.
What I learned
"Make it look nice" doesn't work
The first frontend looked like every AI frontend: each screen lived its own life. Five copies of the money formatter, 22 hand-rolled select components, every screen with its own colours.
So I made a design kit. The reference was Tremor, the well-known dashboard template: calm, dense, the numbers are the loudest thing on the screen. A reference, not a dependency: the agent reproduces that look on the shadcn/ui and Tailwind components already in the project, Tremor itself isn't installed. On top I added:
- one page of rules,
DESIGN.md: colours only through tokens, a type scale, spacing, how charts are drawn, how everything looks on a phone; - a component index that works as a vocabulary for the agent;
- a script that screenshots any screen on phone and desktop;
- a check that rejects a hex colour in a component, a money formatter outside one file, and a bundle over 150 KB.
After that the frontend was rebuilt in one night in six stages, and the agents stopped inventing.
Control the stack and dependencies, at least at the top level
The agent doesn't pick the optimal thing, it picks the most common thing, and that's fine right up until you have to rewrite. My first UI sat on one set of primitives; a few days later the library changed a default and the screens had to be migrated one by one. Rewrites cost both time and tokens.
So the starting spec should pin the language, framework, database, component library, and one command that proves a change is right: types, tests, lint, bundle budget. Not all my choices are optimal even now, but it's already a good iteration.
A health page is mandatory
One screen shows whether the bank imports and the Telegram worker are alive, when the last backup ran, when each bank consent expires and how much AI budget is left, with the age of the last event next to each item. That page is what separates "it works" from "I think it works".
The most valuable part of AGENTS.md is the prohibitions, not the process
The biggest payoff came from a few lines about what must never be done in this project:
- Bank access is read-only; we never pay or transfer.
- Money is stored as whole minor units, never floating point.
- A transfer between your own accounts is not an expense.
- The model may suggest a category; plain code always does the arithmetic.
- If a human decided otherwise, the human's decision wins.
Every one of those was once a mistake that had to be redone, and once it was in the file it never happened again.
A safe process without "approve, approve, next"
Every implementer agent works in its own git worktree, doesn't commit, doesn't push, doesn't see secrets, and in the end just returns a diff. One orchestrator reads each diff, runs the checks and merges. Permissions for dangerous actions, such as SSH to the server, push, or the release script, are granted as a list up front, so I don't click "approve" a hundred times a day, but nothing gets deleted "while we're at it". Deployment always needs my confirmation.
One more piece of advice I didn't arrive at immediately: develop in a container, not directly on your machine. Then you can safely put agents in auto mode without worrying about them wandering somewhere they shouldn't.
Manual testing is part of product design
You describe a screen in two sentences, look at what came out, and only then understand what you actually wanted. "Done" from an agent is a hypothesis until you've poked at it on your phone yourself.
What it costs, and does it work
Monthly it all comes to about €10 for a VPS on Contabo, and even that isn't entirely for this project, because another app of mine lives on the same server in a neighbouring Docker stack behind a shared proxy. A domain is optional. Enable Banking is free for your own accounts, and the classifier on OpenAI runs under a hard $10/month budget that the system enforces itself, reserving the cost of a request before sending it.
So the only thing in this story that really cost money was the development tokens. And even that is simpler than the $2,700 figure suggests: I'm on a subscription, so for me it's $100 a month for Claude, and for that money I wasn't building only this project.
The data lives on one server only I can access, backups are encrypted, and the model sees payment descriptions, not statements. It's not bank-grade security and I know it, but it's my data on my server, not in someone's SaaS.
Does it actually work? My wife and I have used it daily for almost two months, and we both look at the analytics. The dates with Excel are cancelled forever, because everything I used to assemble by hand now assembles itself.
One insight I'll share: it turned out the car in our family eats like another adult. Repairs, servicing and fuel used to hide across different accounts and look like small change; together on one chart they look like something I now treat with respect.
What's next
Before publishing I named the project Keepard, because I had a keepard.com domain sitting idle from the distant past.
The project is open: github.com/sars/keepard. A star helps. It isn't a SaaS and it isn't for sale: a free thing anyone can run on their own server and bend to their needs. There's a demo with an invented household (sign in as guest@keepard.com / keepard-demo-for-everyone) if you want to click around first.
Out of this experience grew the InHouse AI Starter Kit: the foundations for internal systems like this (roles, change history, phone first, an AI budget, one-command release, backups) and the agent practices described above. We've just started using it on two internal projects. But that's another story.
A year ago, building this for yourself meant hiring developers or spending a few months of evenings. Now it's nine days, a token bill and a lot of careful review. It isn't perfect and it wasn't mistake-free, but it works, and it's used.
If you've built something similar with agents, I'd like to hear what your context bill looked like. And if you try Keepard, open an issue with what broke.
Top comments (0)