After 14 years, I finally built my dream personal finance app

A sentimental backstory#

Somewhere around the end of 2012 — after I have been working for a good couple of years in the tech industry — I have noticed something I didn’t expect. Despite having a good salary, I wasn’t saving that much. At that time, I was just planning to rent my first apartment and leave my parents home. If I wanted to pull it off without getting into debt, I had to do that one thing — start to track my finances.

As any sane person, I started with the ultimate personal finance tracking app — the Excel spreadsheet. It’s free (I was using Libre/Open Office on Linux), the format is widely supported, and various software can read it, and it’s private, so I don’t have to sell my finances for $9.99/mo and a risk that I will start to get targeted ads based on my financial situation. The problem with Excel is that you always outgrow it, otherwise we wouldn’t need so many SaaS products.

I won’t bore you with all the details, but throughout the years I have tried every non US centric personal finance app on the planet. GnuCash, KMyMoney, Toshl, iBank/Banktivity, Monarch Money, Every Dollar, YNAB, BudgetBakers, Moneydance, Actual Budget, Firefly III, and others I can’t remember. I was happy with Moneydance for a long time. After I switched from Linux to Mac, I also switched to Banktivity. Later when I outgrew Banktivity, I switched to GnuCash. And when GnuCash messed up my finances with a hidden 1:1 conversion rate from EUR to USD, I finally moved to plain text accounting with beancount.

However, somewhere in the middle of my software hopping journey, I realized that no app can do what I really want. All of them had limitations, but I needed to stay on track with my finances, so I settled on an approach of using what I have while building what I need. And for the next 8 years, starting in 2014, I embarked on a journey to build the ultimate personal finance app and sell it to the world.

I spent most of my free evenings and weekends building, iterating, refactoring, and rewriting it. In the process I learned more about the world of finances: double entry bookkeeping, fundamental accounting equation (A = L + E), investments, stock options, depreciations, database design, etc. Every time I learned something new, I wanted to add it to my app, which usually meant a refactor. Throughout the years I have iterated on what the app should be, and how should it work. It started as a web app, in an era when subscription fatigue wasn’t an issue yet. But once people started to get tired of subscriptions, and hesitant to share their deepest secrets with a random online service, I pivoted into a desktop application in Java/Kotlin. And I always believed that desktop applications should be available to everyone, no matter if you like apples, penguins or a weirdo who likes windows. I suffered from apps not being available on Linux, so I didn’t want to become one of these apps. But building a cross-platform native (i.e. non-web/electron) app — is hard. I wanted to have everything — fast data entry, accessibility, keyboard navigation. Good luck building it in JavaFX.

So I decided to suck it up to electron. And then I tried Tauri. Until eventually, I realized that web UI is a pile of glue-your-own components together that don’t really speak the same language. At least with JavaFX or QT you get a rich library of well integrated components, unlike the web where your search box, your date input, and your math input — are 3 different npm packages by 3 different people that share zero visual resembles to each other. And so, in the pursuit of reaching my goal of building an app for myself first, and as a product second, I looked into TUI or text-based user interface. Yes, these old DOS looking apps that you can still notice here and there on the screens of cashiers at a supermarket. Very limited set of UI elements, but superb keyboard control.

Until eventually I landed on plain text accounting and beancount, and realized that I can do everything I need from vim. In combination with BQL (the beancount query language) and the Fava web-UI I was able to get 80% of what I need. The remaining 20% were tucked in a “some-day” drawer, that never came. And so, somewhere in 2022 I have abandoned the idea to build my own personal finance app. Until, something happened.

A short introduction to plain text accounting#

If you are familiar with plain text accounting (PTA for short), you can skip this section. For the rest of you here is a short introduction.

PTA, as the name implies, mean you store your finances in plain text. There is no database, and not fancy input interface. The database is a collection of (or one huge) text files, and the input interface is vim your favorite text editor. Here is a PTA transaction:

2026-10-20 txn "Walgreens" "Apples & Bananas"
    * Assets:Chase          -100 USD
    Expenses:Groceries

As you might have guessed, this transaction simply says that I paid $100 from my Chase bank account, to Walgreens, buying apples and bananas, categorizing the expense as groceries. By itself, the file does not mean anything. But with tools around it like beancount, ledger, and many more — you get the necessary enforcements, and sometimes even reporting. No proprietary locked down file, no cloud, and no app. Combine it with git and tools like sed and you have a free undo, bulk rename, and audit log. If tomorrow all the PTA apps stop to exist, your files are still readable, and you can still keep using the old version to do stuff, because most of this software is feature complete and does not need to be enhanced or improved every Friday afternoon.

It is the ultimate file format. I even read about people on HackerNews running their company accounting on top of PTA by using Git for approving or rejecting purchase requests. I also use PTA for my small, one man, business. And I really like PTA. It’s the markdown of finances.

But with great tooling around enforcing the correctness of PTA, the tooling around displaying data still lacks. Therefore, even though I had my custom BQL queries and the Fava Web-UI, I still wanted a bit more.

My Dream personal finance app#

Let me introduce you to books.

Books is a TUI that has an extensive feature list. It has full keyboard navigation support, with vim like motions. Press gt and you are looking at the transaction list, gn takes you to Net Worth. Inside every page you see what you need. Graphs, important numbers, tables that can expand and collapse. Income & expense, with “winners” and “losers” each month; average saving, income, and expense numbers; who were the movers compared a previous month or the 12-month average. A net worth graph across the entire past 14 years of transactions, with groups by employer, and country of residence. Full Dutch tax return module that will calculate Box 1, Box 2¹1I have no “substantial interest” in a company, so this box is useless for me at the moment. , and Box 3. Comprehensive investment tracking with asset allocations, holdings, and all time performance. Real estate tracking, with remaining mortgage, costs associated with the property. A breakdown of every trip with expenses for said trip, averages, and trip duration. Custom module to track my personal boxing sessions, and vacation hours at my work (yes, I use PTA to track these as well). Income & expense reports, VAT filing, expenses by vendor, and automatic Stripe transaction import for my business. It’s fast, responsive, and shows me everything I need to see. And with automatic checks and balances, it shows me warning or errors when things don’t match: a wrong #travel tag, missing Stripe payout, a mortgage that is not on track, and more.

It’s more than I ever dreamed of building. And as far as I know, it’s more than any software today can do. The only thing it doesn’t have is tracking car ownership, since I don’t own a car at the moment (thanks Dutch infrastructure). But when I will need it, it won’t be hard to add. The nice part is that it all uses standard beancount format. The software is just a UI on top of the files. My data stays open, accessible, and readable to me, while the app helps me view it better, and spot errors.

And the crazy part?

It took me between 5 and 10 hours to write the design documents for each feature, review the results, and iterate. And it took Claude about 20–30 hours to build it. A week of work, with 80% of it is Claude running autonomously. It costed about ~€25 (a 1/4 of my €90/mo Claude Pro subscription).

The closest estimate I have to a paid product is Maybe finance (rebranded as Sure later), which according to it’s Co-Founder Josh Pigford, took about 2 years of development, and a budget of $1,000,000 ²2Sure/Maybe backstory . Maybe and Josh failed to find a product market fit, and decide to release Maybe as open source. From my high-level overview, other than automatic sync (that I never really wanted), and Maybe being a web-app, books is much more capable in every other aspect. And most importantly, it’s built exactly for my needs.

So where can you get it?#

Here is the thing… You can’t.

You will never get it. I will never release it. It’s 100% vibe coded, in Python (which I don’t know that well). But more importantly: it’s built for me, for my needs. Your needs are different. You might be using Workday to track your vacation days; might not have investments; and judging by the analytics of this blog, there is only 2.5% chance that you file your taxes in the Netherlands.

This is, what they call today, a vibe-coded slop. Most people wouldn’t even touch it. And even if they would, I have no intention to maintain it and support your special cases, which I have no knowledge of, because I never experienced them. I’m not even talking about the business model of a TUI app for B2C in the niche of personal finance. It’s brutal. Actual Budget tried, and they failed, so now they are open source. The only successful product I know of in this niche, which appeared while I was trying to build mine, is Lunch Money by a solo founder named Jen.

So no, you can’t get it. But there are some lessons to take from this experiment.

What does it mean for the future of software, software development, and developers?#

The more I speak with people around me, the more I realize that nobody knows what is going on and what to expect. People go from crazy scared, to AI-psychosis in a span of few days. Hell, even I do. And so everyone is trying to predict things: what’s the future of software engineering, what’s the future of SaaS, and what’s the future of humanity. So let me make my predictions.

Is SaaS dead?#

Every time I go on HackerNews, LinkedIn, or Reddit — I see a bunch of people saying how SaaS is dead. How they spent 5-10 hours to build a commercial tool that requires a $29/mo subscription and a team of engineers to support and develop it. The recent trend seems to be vibe coding your own Android TV interface without any ads or bloatware. Everyone is pointing their Claude to their Android TV and says “Hey Claude, make it fast, no ads, and no bloatware”, and it seems to work. And then, in the spirit of #though-leadership and #ai-forward-thinking they write a post about how SaaS is dead.

I don’t think SaaS is dead.

If you are in the business of creating $29/mo SaaS for developers — then yeah, you are going to have a bad time. Tools like analytics, workflow runners, or cron monitors — no longer make any economic viability when I can vibe code them in half a day. Software development fragmentation is a real thing I oppose, and with Claude I can take back my data ownership and create better tools rather than trying to work around 10 SaaS with their APIs and pinky-promises to never break them. Sure, it increases maintenance burden, but for internal tools, I’d prefer to have access to the source code + Claude, then trying to reach out to your support and ask for the hundredths time to “please add this feature that I really need!”

However, if we talk for a moment about non-developer software, then no, I don’t think SaaS is dead. Despite the fact that I spent 40 hours and €25 to build my dream app, you need to remember that I have about 14 years of “personal finance” experience. I know how to read net worth graphs, how to track investments, and how to balance accounts. If you ask someone who has no idea what they are doing, to build an app like this, they will produce AI slop that is useless.

I guess what I am trying to say is that knowledge and context — matter. I know nothing about aero-dynamics, and if I prompt Claude to “pretty plz build me car aero-dynamics simulator make no mistakes” — I might get something that looks amazing, but I would have zero tools in my arsenal to assess whether it’s good and correct. My app is correct because I filed my own taxes for 2 years, I know what most boxes mean in the tax and VAT filings. I know what is reverse-charge, when to file ICP, or how to calculate my box 3 taxes. And I have a reference to check against. But most people don’t have them, and I guess this is the reason that most personal finance apps focus on US taxes, since they are developed in the US.

Moreover, most people simply lack the technical knowledge to bring something to production past the “plz build me an app” phase. This is where the popular meme comes from:

Hey everyone, check out my cool web app that I built! You can access it here: http://localhost:8080/index.html

And this brings me to the next question.

What’s the future for software engineers?#

For a very long time I have been reluctant to let go of the code. I always said to myself — I am a software engineer, I am good at writing code. I invested a lot of my time into design patterns, learning how to write clean, and maintainable code. And then you come, with your stupid text generating tool, and tell me you can do a better job than me?

But with years, I have learned that software engineering is not about writing code. In fact, software engineering is only about 10-20% of writing code. And with Claude Opus 5.5, it’s even less. Most of the features were one-shot prompts, with iterations over design and what bits to include. But when I wanted to add a new module, say vacations, I just told Claude what I want, and after about 30 minutes I got a working tab. From there, it’s a back and forth of fine-tuning, what data to display, and asking “can this be done?” (hint: 95% the answer was yes, even if it involved refactoring the whole app).

I wrote zero lines of code manually. Hell, I didn’t even look at the code. My value was in knowing what to build, how to build it from a high level perspective rather than focusing on what design patterns to use, how to test it, and, finally, writing good prompts. I said in the past why engineers should learn to write, and I still think it holds true today. In fact, I think it’s more important today than ever. Writing a design document that can be so detailed and cover all the edge cases — is what differentiate a good LLM output from pure slop.

But this creates two problems.

The first one we, software engineers, can’t control. When Dario goes on stage and says “coding is solved”, there will be layoffs. No matter how hard you will argue with your manager or CTO that “no, you can not let AI write code without humans in the loop”, they will keep replying “sry, dario said you can, so bye!”. Do you need so many engineers? I don’t know. But I do know that if a team of 5 could ship one feature per week pre LLMs, then today they can ship 5 features a week. Isn’t that the productivity you are after? In the end, there is a capacity for the human brain in terms of context switch. So you can not expect to let 4 engineers go, and the remaining one to build 5 features in parallel. But hey, I can’t play Don Quixote with the C-level. Most of them are irrational, and live in fears — just like us — albeit their fears are different.

The second problem is how we approach software engineering. A typical developer archetype is an anti-social person who doesn’t want to do anything related to product management, let alone speaking to clients. Hell, leave me alone and let me write code. Algorithms, design patterns, clean and maintainable code. But I think the people who would benefit the most from the near future are technical product manager types.

Don’t get me wrong, most PMs are like engineers, focused too much on what it means to be a PM, unwilling to step into uncharted territories. But I’ve met PMs who are getting technical or even hands-on (pre LLM era). These people can benefit the most from LLMs. Coding is a solved problem, mostly, and what is left now is to know what to code. And in order to know what to code, you need to go and ask people what they want, observe them, and be able to identify problems in real world. Useless apps existed before LLMs as well, it’s just that it took longer to produce them. And good software was never about the code. In fact, if you look at most good (=useful) software, you will actually notice that they don’t focus too much on the code. It is sad, because people no longer focusing on things like resource optimization, and every software is a 4GB ram hogging bloatware. However, on the other hand, I have noticed that with LLMs people are actually developing native apps without knowing Kotlin or Swift. So who know, with RAM getting anywhere between 300% to 500% more expensive than pre LLMs — perhaps we will see software that is optimized for a modest 4GB of RAM systems.

But LLMs write bad code!#

All across the internet I see how people scream that LLMs write bad code, full of security vulnerabilities. And it confuses me because don’t people write bad code as well? No to bash anyone but as I type this there is a critical PHP vulnerability; my local supermarket is recovering from a cyberattack; and France got ~3,000 fridges defrosted — all due to human written software. I wrote bad software, and anyone I know wrote bad software. Writing good software is hard.

Yes, LLMs write bad and buggy code, sometimes. But like with human written code, you need to have guardrails for what you ship. Because you no longer write the code, does not mean you can disregard basic security and QA measures, which is another point against the “coding is solved” camp.

And in certain cases LLM can spot and fix errors. I had a typo in one of my BQL queries, which resulted in some reports ignoring certain transactions. Claude spotted it and told me about it.

Generalization vs Specialization#

I never understood people who specialized in one particular field. Sure, you could get a lot of money if you become a Linux kernel driver expert, but at the same time, if your expertise is frontend development, then you could expect that if not LLMs, then other tooling would make writing HTML obsolete. Frameworks got better, and tools around it made it more accessible to non developers. At the same time, if you are someone who can set up a CI/CD pipeline, write the backend and the frontend, talk to customers, and do accounting — then LLMs can increase your productivity ten folds. But you need to get decent skills in all these disciplines. And I’m glad that I was able to build a career in times when there was no such thing as frontend or backend engineer, and “doing DevOps” meant running your own LAMP stack on your own VPS rather asking the “DevOps department” to provision something.

Sure, specialization in certain fields is still viable career path. I wish I could understand how LLMs work, or how to write a custom NVIDIA driver to optimize their execution on a particular GPU. I bet these people are having lots of fun, in addition to a very nice compensation.

You probably know this popular quote:

A jack of all trades is a master of none.

But very few people know how this quote ends:

But oftentimes better than a master of one.

And I strongly believe in this.

Conclusion#

I don’t really know how to end this article. It’s already longer than I expected. I guess like with my previous article, this is just a dump of my thoughts and experiences.

This is a very exciting time to be a software engineer, because I can finally build the things I wanted to build but never had the time. I can experiment with features that would take weeks to develop, just to be proven invaluable in the end, by spending only a few hours. However, at the same time it feels weird to say “I built it”. And while prompting and waiting for a result, I can’t ignore the little though in my head, that I am turning my profession into a slot machine: here is some text, let’s see what I can get back. But perhaps it was always like this, with the exception that the text was not English but some obscure syntax that no human, other than the ones that call themselves software engineers, could understand, and the reward just took longer than a 15-minute coding session?