BR-Budget.
Software I
did not build for you.
An experiment where I test a hypothesis: what happens when the primary user of a finance application stops being a human and becomes an AI agent acting on their behalf. I do not know if I am right. I am building to find out.
In May: PLN 1,273 on food, 87% of the monthly limit.19:42
What if the main user
of the application is not a human?
Future software will not be applications for people. It will be a set of data and hard domain rules for an LLM agent standing between the human and the system.Hypothesis I am testing · 2026
I call this agentic-first. I do not want a human to click around for data if an agent can fetch it, understand it and return with a decision. The UI is still needed, but it stops being the place of daily work.
We have a precedent. Mobile-first also sounded provocative twenty years ago. First you designed for desktop and mobile was an add-on. Mobile-first reversed that logic.
Agentic-first is a similar shift, only deeper inside the product. It is not about bolting an endpoint onto an existing dashboard. It is about designing data, rules, permissions and decision history so an agent can really work with them.
The human taps, clicks and reads. The app must be beautiful, clear and fast.
The human talks to the agent. The agent reads the API. The product must be machine-readable.
The human tells the agent: “check whether I can afford a new lawn mower”. The agent connects to the API, pulls the balance, categorizes expenses, checks obligations and returns an answer. The human never opens the dashboard.
The LLM does not know where I eat out, what subscriptions I have or how I account for VAT. These are data and rules living in the application. The application must be readable for the agent.
It sounds provocative. I may be wrong. That is why I decided to test it in practice.
Finance apps are great at measuring expenses. They do not help you save. Those are two different things.
API-first, agent inside.
Why a budget app.
I had used YNAB for years. I paid for it. The thought “why pay for something I can build myself” kept growing. Less than a year ago I tried to build Solon, a personal finance startup. Back then the project hit the real cost of development.
Today, in 2026, I took the same project from zero to production in a few days. This is not a self-congratulatory anecdote about speed. It is a premise that changes the calculation for a founder or CTO building internal tools.
Solon
The same idea. It broke on time and cost. Buried.
BR-Budget
MVP od zera do produkcji w kilka days. Inna technologia, inny tryb pracy.
The architectural decision that changed everything.
“Why am I building advanced filters and reports if the agent will soon generate them on demand?”
I started classically, UI-first. Screens, transactions, categories, reports. In the middle I stopped and shifted priority. API-first. Agentic-first.
- API with full CRUD for every object
- Per-user API keys connected to Claude Desktop, ChatGPT and Hermes
- Inherited permissions; the API key sees exactly what the user sees
- The UI remains for control, correction and trust, but it does not have to be the daily interface
Netflix, Supabase, Lovable, OpenAI and 3 others.
Total: ~PLN 643 / month.21:08
After the purchase, there is still a 4-month fixed-cost reserve.
Yes. But I am adding it to Pause for 2 days.21:09
I really run these queries with my agent through the BR-Budget API.
The agent reads balances, categorizes expenses and suggests decisions without opening the dashboard.
What you get when you log in.
“This is not hello world. It is a YNAB-class app with Polish context and an agentic-first API.”
Zero-based budgeting, alternatywny tryb lekkiej kontroli, the Pause module, atomic transfers, statement imports from ING and Nest Bank, AI classification with fallback, and refunds attached to the original category.
Inside: the decisions that matter.
“Experimental application, but not a hobby app.”
Amounts are stored in grosze. A transfer has a shared transferId and outflow/inflow roles. Bootstrap loads snapshot, settings and import coverage in one request. Agent API runs in a separate authorization scope.
Stack chosen for iteration speed
Speed is not the point.
“AI in the development loop changes build speed by an order of magnitude. The point is what you do with that speed.”
The MVP was built faster than would have been possible even a year ago. But BR-Budget is not really about speed. The most interesting question is: what suddenly becomes worth testing when a prototype with a real domain can reach production in a few days?
Gamifying savings is a classic trap. People do not need points to save. They need fewer decisions.
What the experiment showed.
The first version had points, streaks and rewards for staying on budget. I cut it after the first weeks. It did not work.
I replaced it with the Pause module. Bigger purchase? You enter the item, amount, store link and answer a control question. The system calculates a decision lockout proportional to the amount.
A cooling-off period is a real behavioral mechanic, not fake gamification.
Large air purifier
I am currently building Pay Yourself First: automatic income detection, suggested saving amount, execution verification and adaptive recommendations. Decision elimination, not motivation through points.
Mobile
od pierwszego daysa.
Because the agent reads through the API, but the human sometimes looks. When they do, they look on a phone.
The system informs the agent, not the other way around.
Today the agent asks BR-Budget: “what happened?”. The next step is more interesting: BR-Budget tells the agent that something happened.
Income arrived. A subscription renewed. A category crossed its limit. An expense appeared that looks impulsive.
This is the moment when the app stops being a place I check. It starts being a system that speaks up when it has a reason.
Pay Yourself First
- Automatic income detection
- Suggested amount to save
- Execution verification
Push, system to agent
- Income and expense signals
- Recurring subscription renewals
- Category or limit overrun
A fuller picture of finances
- Assets, earnings, liabilities and goals
- Warranty tracker from receipts
- Statement import from more banks
This is not a client case study.
It is a manifesto.
I am building BR-Budget because I want to test whether software can be designed differently: less as a place to click, more as a system of data, rules and decisions that an agent can safely work with.
I may be wrong. I am building to find out.