Two years ago, I just wanted to replace my paper budget. Somehow I ended up building Budgetum.

This August marks two years since I started working on Budgetum.

And apparently ChatGPT could help reconstruct a surprising amount of those two years better than I could.

I used it constantly while building Budgetum—discussing bugs, database decisions, UI ideas, App Store copy, user feedback, analytics, pricing, and probably hundreds of ideas that never made it into the app.

For this post, I used the conversation history that was available to help me piece together what happened. I also went through old posts and release history, corrected the things it got wrong, and added the parts that mattered to me.

So this is not exactly an AI-written success story.

Especially because there isn't really a success story.

Budgetum is still a small app. Growth is slow. I still don't understand marketing very well. It hasn't turned into some indie-app business making thousands of dollars every month.

But it survived for two years.

And something that started as a rough personal tool became the largest thing I've ever built completely by myself.

1. 1

   August 2024

   From paper to prototype

   The first version copied the system that was already working on paper.

   • Sections, categories, and planned amounts
   • Transactions with plan-versus-actual progress
   • Local data with no Budgetum account or server
2. 2

   The first months

   From prototype to a real mobile app

   Building the product also meant learning everything around publishing it.

   • First iPhone release after roughly three months
   • Android followed soon afterward
   • App review, signing, purchases, icons, and store screenshots
3. 3

   2025

   From budget plan to money model

   Each new question forced Budgetum to understand more than a monthly plan.

   • Contacts, itemized receipts, accounts, and transfers
   • Custom periods and bank statement matching
   • An almost two-month category-model rewrite
   • Ads removed; optional one-time Pro added
4. 4

   2026

   From tracker to analytics platform

   Months of history turned simple charts into much deeper ways to explore data.

   • Guided onboarding with starter categories and plans
   • Comparisons, trends, calendars, saved sets, and goals
   • CSV import, export, and multiple-currency improvements
   • Budgetum 1.7 and local-first Desktop Analytics

Out of curiosity, I checked a few anonymous event counters while writing this:

329,394

transactions

10,495

accounts

11,433

contacts

4,483

recurring templates

These count actions, not financial data. A transaction event says only that one was created; it contains no amount, category, or description.

Before Budgetum, I wasn't a mobile developer

I'm a developer from Ukraine.

Most of my professional experience was in web development—PHP, Laravel, MySQL, and later Vue.

For years I worked on a large CRM/ERP-style web application. It had customers, sales and purchase orders, inventory, accounting, payments, bank transactions, reports, workflows, and a lot of other business logic.

So complicated financial data wasn't completely new to me.

Mobile development was.

When I started Budgetum, I had never released an iOS app. I had never released an Android app. I barely knew Flutter.

I knew how to build large web systems, but I knew basically nothing about App Store review, signing certificates, mobile purchases, ASO, retention, mobile UI conventions, or why something that works perfectly on my phone suddenly breaks for somebody living nine time zones away.

Budgetum taught me all of that.

Sometimes painfully.

It started because I couldn't understand where my own money was going

I didn't start Budgetum because I saw a great business opportunity in personal finance.

I started because my own budgeting wasn't working.

I had several bank accounts plus cash, and the analytics from the banks weren't useful to me. They would tell me things like:

Supermarkets. Entertainment. Shopping.

Okay.

But that didn't tell me what I actually wanted to know.

I tried a lot of budgeting apps. Some were good. A few definitely influenced Budgetum. But I kept running into things that annoyed me:

• Create an account before doing anything.
• Connect your bank.
• Start a trial.
• Use our categories.
• Use our budgeting philosophy.
• Pay if you want more than a few categories.

Or the app was a nice expense tracker, but the actual budget plan felt like an optional feature hidden somewhere else.

Eventually I did the least technical thing possible.

I wrote my budget on paper.

Not Kids — $500, but things like daycare, diapers, extra classes, and toys. Things I actually understood.

I wrote down the expenses I knew were coming and then marked them as they happened. That already worked better for me.

Then I got to groceries.

I had absolutely no idea how much we really spent there, so I started breaking that down too: food, drinks, household products, cigarettes, random things.

And I started discovering expenses I hadn't really noticed before.

Apparently buying a game occasionally looks very different from seeing a “Games” total at the end of several months.

That was the original Budgetum idea.

I didn't want a financial coach. I wanted a digital version of that piece of paper.

So I opened Flutter and started building it

The first version was tiny compared with Budgetum today.

You created sections. Inside them you created categories. You entered how much you planned to spend. Then you added transactions and watched planned versus actual spending.

That was basically the product.

And honestly, I thought that was probably enough.

About three months after starting, somehow I had an actual iPhone app in the App Store. Android followed soon after.

That still feels strange to think about because a few months earlier I had never made a mobile application at all.

Finishing the code also turned out not to mean the app was ready to publish. I had to design an icon, assemble store screenshots, write descriptions, choose keywords, and explain the whole product in a handful of images.

All of that was new to me too. The icon and screenshots went through more versions than I expected, and learning how to present Budgetum became its own project alongside building it.

One early decision accidentally became the identity of the app

I also made Budgetum completely local.

At first this wasn't some grand privacy strategy. I was one developer building a personal budgeting tool.

Why would I create authentication, a server, an API, account recovery, synchronization, and all the infrastructure around it if the app could just store the database on the phone?

So Budgetum worked offline.

No Budgetum account. No mandatory bank connection. No server containing everyone's financial records. Your budget database stayed on your device.

Over time I realized I liked this much more than I originally expected. It became part of what Budgetum is.

There are downsides.

People regularly ask me for family sharing, multi-device sync, and bank connections. Every one of those features becomes significantly harder when the starting principle is “the app should work without my server.”

I'm still thinking about them.

But two years later, I still don't regret starting local-first.

Then the “simple budgeting app” started growing

This is probably how every software project gets into trouble.

You solve one problem. That creates two new problems.

Transactions created the need to know who the money went to, so I added contacts—stores, cafes, pharmacies, people.

Then I wanted to understand supermarket purchases better. A single $100 supermarket transaction wasn't very useful if it contained food, cleaning products, and something for my child. So receipts became itemized.

Then came accounts: cash, bank cards, savings, debt, and transfers.

Once accounts existed, Budgetum had to understand an important difference:

Moving money is not the same thing as spending money.

Transferring $500 from checking to savings isn't a $500 expense. Correcting an account balance isn't spending either.

A lot of my old accounting-system experience suddenly became useful.

The little budgeting app was slowly becoming a model not only of what I planned to spend, but also where the money actually was.

My most flexible idea became one of my biggest mistakes

One of the decisions I was proud of in the beginning was that every month could have a completely different structure.

Want to rename a category next month? Fine. Move it somewhere else? Fine. Delete it? Fine. Create an entirely different budget? Also fine.

Maximum flexibility.

It sounded great—until I wanted proper reports, filters, trends, import and export, and the ability to move a transaction from one month to another.

Then it became a nightmare.

If “Groceries” in March and “Food” in April were technically completely different objects, what exactly should a yearly report show?

What happens when someone moves an April transaction into March and its category doesn't exist there?

I had basically given the user so much structural freedom that the internal data model became extremely difficult to scale.

So I spent almost two months rewriting it.

Categories and sections became global entities, while monthly plans remained flexible on top of them.

The funny part was that I tried very hard to make the update look boring to users. Internally, a huge part of Budgetum had changed. Externally, ideally, almost nothing looked different.

That was probably my first real lesson in what maintaining software feels like.

Sometimes the update you're most proud of is the one where the user says:

Okay. Looks the same.

Then I discovered that dates are evil

Around the same period, a user contacted me because all of their May transactions appeared to have disappeared.

That's a message you really don't want to receive when you're making a financial app.

The data fortunately wasn't deleted. The problem was date and timezone handling.

Under certain conditions, the app could think a date belonged to another day or even another month and create what looked like a duplicate monthly plan.

I fixed it.

Then discovered another timezone problem.

Then fixed that.

Then changed more of the date logic.

Before Budgetum, a date was just a date to me.

After Budgetum, I have opinions about dates.

For a while, Budgetum had ads

This part is funny in retrospect.

I wanted Budgetum to be free, but I also thought: “Well, apps need to make money somehow.”

So I added a small banner ad. It wasn't aggressive. It wasn't blocking anything.

And eventually it had earned approximately...

$2.

I think I disliked having the ad more than the ad liked making money.

More importantly, I started feeling that the whole idea was wrong. Creating an annoyance and then selling the solution to that annoyance didn't fit what I wanted Budgetum to be.

Here is something unpleasant. Pay me and I'll remove it.

So I removed ads completely.

Later I changed the monetization to an optional one-time Pro purchase. No subscription. The core budgeting functionality stays free.

Pro is for things I consider additional or advanced—higher limits for some optional tools and features such as saved sets and bank statement matching.

Is that the optimal business model?

Probably not.

But I feel much better about it.

It still seems strange to me when an app aimed at people trying to control their expenses immediately gives them another monthly expense.

Users started changing the direction of the app

One thing I didn't expect when I started is how many features would come from one person describing one specific problem.

Someone budgets from payday to payday instead of from the first day of the month. That eventually leads to custom budget periods.

Someone wants to reconcile what they typed manually with their bank statement. That becomes statement matching.

Someone wants export because they don't want their history trapped inside one app. That eventually grows into CSV export, import, and Desktop Analytics.

Someone says the first screen is confusing.

That's painful to hear, but they're probably right.

Budgetum was originally made by me, for me. Of course I understood it. I knew why the Budget screen came first. I knew what sections meant. I knew why Accounts were optional.

A new user didn't know any of that.

At one point, a user simply told me they had downloaded the app and still couldn't fully understand it.

That kind of feedback is more valuable than “great app!”

It eventually pushed me toward a proper first-time setup with starter categories, currency, language, and planned amounts instead of dropping everyone onto an empty screen and hoping for the best.

One of my favorite things that happened had nothing to do with downloads

A teacher started using Budgetum while teaching personal finance.

At one point, a class of 22 students was using it.

That was surreal.

I started the app because I personally wanted to replace a piece of paper. I definitely wasn't thinking: “One day somebody will use this to explain budgeting to a classroom.”

Feedback from teaching also influenced the app.

The Needs / Wants / Savings view came partly from thinking about how to explain budgeting more clearly to beginners without forcing the entire app into one budgeting method.

That's the kind of feature I like most.

You can use it.

Or ignore it completely.

That eventually became the philosophy of Budgetum

Something became clearer to me while using the app myself.

I don't actually believe a budget should always be a strict rule.

For me, the first few months of budgeting were mostly measurement.

I guessed groceries. Tracked what really happened. Adjusted the next month. Tracked again.

After a few months, I finally knew what “normal” spending looked like.

If I planned $500 for something and spent $600, I didn't go back and edit history to make the plan look correct.

The difference was the useful information.

It told me something.

That eventually became the idea I now use when thinking about Budgetum:

Understanding first. Rules second.

I don't care whether somebody uses zero-based budgeting, 50/30/20, envelopes, a loose monthly plan, or just tracks a few categories they personally care about.

If the app helps them understand what is happening with their money, it is doing its job.

2026 became the year of trying to understand the data better

Once people had months of transactions inside Budgetum, basic charts stopped feeling like enough.

I wanted questions like:

• How is this month different from the previous one?
• What changed compared with last year?
• Which category is growing?
• What do I spend at this particular store?
• What does this tag actually cost me over six months?
• Where is my money now?

So analytics grew a lot: Needs / Wants / Savings, period comparisons, trends, category and account histories, a full-year spending calendar, saved transaction sets, custom periods, and bank statement matching.

And then I ran into a very simple limitation.

A phone is small.

You can only put so much financial information on a small screen before “analytics” becomes a collection of cards you scroll through forever.

Desktop Analytics became my weird solution to that

The obvious solution would be to create Budgetum accounts, upload everyone's transactions, and build a web dashboard.

But that would mean changing one of the fundamental ideas of the app.

So I tried something different.

Budgetum can export its data. The Desktop Analytics page can open that export in a normal desktop browser and process it locally.

The file doesn't need to be uploaded to my server.

You get a big screen for breakdowns, trends, calendars, accounts, and transaction exploration while keeping the original local-data approach.

I really like this idea because it feels like a Budgetum solution rather than just copying what every cloud finance app already does.

Processed locally

Budgetum

Your financial data stays on your device.

Your export

You choose when to create and move the file.

Desktop Analytics

The browser processes the export locally.

Your export does not need to be uploaded to Budgetum's server.

AI tools also helped me a lot while developing this part.

Not AI reading users' financial data—AI helping me write and prototype software.

The tools available to one developer in 2026 are completely different from what I had when I started Budgetum two years ago. There are things I can experiment with now that I probably wouldn't even have attempted alone before.

And now Budgetum 1.7 exists

The latest stage is 1.7.

Desktop Analytics. Importing CSV data from Budgetum, YNAB, and other apps through column matching. Better mobile analytics. Improved bank statement matching. Better support for accounts in different currencies. A huge dependency and framework upgrade behind the scenes.

And a ridiculous number of small UI changes that took a lot of work and will probably be summarized in the App Store as:

Various improvements.

Software development is cruel like that.

Early Budgetum

Budget plan

Category history

Budgetum in 2026

Budget overview

Analytics

Select any screenshot to view it at full size.

Somewhere in all of this, strangers actually started using it

This part is still hard for me to process.

At around the 1.5-year point, Budgetum had roughly:

• 8,000 installs
• 170 Pro purchases
• 250 people using it regularly each month

Those aren't startup numbers.

I don't have millions of users. Budgetum isn't paying for an office full of people.

But the first version existed because one person—me—wanted it.

So thousands of installations still feel like a lot.

Installs only tell me that somebody tried the app, though. The more interesting question is whether they actually used it.

That's why the activity behind those installs means more to me than the install count itself. Some people didn't only try Budgetum. They kept recording what happened with their money months later.

Sometimes I read a review from somebody who has been using Budgetum for six months. Someone found it through an online recommendation. Someone says they bought Pro even though they didn't need it, just because they wanted to support development. Someone compares it positively to apps made by companies infinitely bigger than Budgetum.

Those moments are weird.

Because on my computer, Budgetum is mostly a list of bugs, TODOs, and things I want to redesign.

On somebody else's phone, apparently, it is just an app they use to manage their life.

I try to remember that.

Programming was not the hardest part

This may be the biggest surprise of the whole project.

I spent most of my career as a programmer. You naturally start believing that building the software is the difficult part.

It is difficult.

But getting anybody to know the software exists is an entirely different profession.

I tried App Store optimization, different screenshots, different descriptions, keywords, online communities, YouTube, tutorial videos, advertising, contacting bloggers, Product Hunt, and building a website even though I'd much rather build another feature.

At one point, the first Product Hunt launch basically disappeared without anyone noticing.

Sometimes installs increase and I don't know why. Sometimes they decrease and I don't know why.

People install the app, create a few categories, and disappear.

Why?

Was onboarding confusing? Was the app too complicated? Did they just change their mind about budgeting? Did the screenshots promise something different?

A programming bug eventually gives you a stack trace.

Marketing does not.

There is also an uncomfortable contradiction I still think about

I built Budgetum because other budgeting apps annoyed me with complexity.

Two years later, Budgetum has accounts, transfers, receipts, contacts, tags, recurring and future transactions, custom periods, analytics, saved sets, statement matching, account goals, different currencies, imports, exports, PDF plans, web sharing, and Desktop Analytics.

There are even three tiny games hidden inside it because apparently nobody was supervising me.

They have been opened 494 times in total, which is 494 times more than a budgeting app probably needs.

Merge DropSnakeBalance

So yes.

The simple app has become complicated.

I think about this a lot.

My solution so far is not to stop adding useful things. It's to make them optional.

You should still be able to use Budgetum approximately the way the first version worked.

Create a few categories. Set a plan. Add expenses. See what happened.

Done.

You don't need accounts, receipts, tags, recurring transactions, statement matching, or Desktop Analytics.

And you definitely don't need the games.

The challenge now isn't adding more functionality. It's keeping a large amount of functionality from getting in the way of somebody who only needs 10% of it.

I think that's going to be one of the most important problems for year three.

What would I do differently if I started today?

A lot.

I would design the category model differently from day one.

I would think about custom budget periods much earlier.

I would never underestimate timezones.

I would add proper product analytics earlier instead of spending months guessing what people did after installation.

I would work on onboarding before some of the advanced features.

I would probably think about import and export earlier too.

And I would spend more time thinking about how I was eventually going to explain all of this in six App Store screenshots.

But there are a few things I wouldn't change.

I would still start local-first.

I still wouldn't require an account.

I still wouldn't start with a subscription.

And I would still build the app around a budget plan rather than around automatic transaction importing.

Those decisions made some things harder.

But they also made Budgetum what it is.

Two years later

Budgetum is still built by one developer in Ukraine.

There isn't a product team deciding what goes on the roadmap. There isn't a designer handing me finished screens. There isn't a marketing department.

Most decisions still begin with me using the app and thinking:

This is annoying.

Or somebody sending me a message that starts with:

Could you add...

There are still big things I don't know how I want to solve: sync, shared and family budgets, better bank integrations, maybe more desktop functionality, and probably a lot of existing things that should become simpler rather than bigger.

But I understand the app much better now than I did when I started.

Budgetum isn't supposed to tell you the correct way to manage money.

It's not supposed to make you feel guilty because a category turned red.

And it doesn't need to automate every financial decision.

It's a tool.

Make a plan.

Record what actually happened.

Understand the difference.

Adjust.

That's basically what I was doing on paper in August 2024.

I just took a slightly ridiculous two-year detour to turn it into an app.

Thanks to everyone who has used Budgetum, reported a bug, suggested something, left a review, bought Pro, tested an unfinished idea, or simply told me that something didn't make sense.

A surprisingly large part of Budgetum exists because one person somewhere asked a question I hadn't thought about.

Two years ago, I started Budgetum because I couldn't find the budgeting app I wanted to use.

Two years later, I'm still building it.