How I Built a Personal Budget App with Vibe Coding
A development story covering card notifications, statement OCR, cash expenses, budget comparison, privacy choices, and the testing needed to make the numbers reliable.
How I Built a Personal Budget App with Vibe Coding
There are many polished budgeting apps, but none matched the way I wanted to track spending. Each card follows a different approval period, and I wanted card payments, cash expenses, and fixed costs in one place. I also wanted to import older history from statement screenshots without sending financial data to an external server.
I therefore built a personal Android app by describing features to a conversational AI, installing each result on a real phone, and reporting the problems I found. This was vibe coding, but not a one-prompt success story. The real process was to split requirements into small pieces, run the app, compare the totals, identify the cause of mismatches, and add tests before moving on.
All personal details and real monetary values have been removed from the screenshots in this article. Chart areas that could reveal approximate amounts were also covered.
It began with a need for one clear summary
The first goal was to show the monthly budget, current card approval-period total, monthly cash spending, and overall spending status on one screen. Separate tabs were added for summary, cards, cash, budget, and imports.
The earliest version was a small MVP that detected new card-payment notifications through Android's notification access service. It processed only the selected card issuers. Bank login, account access, SMS and contact reading, advertising SDKs, and server uploads were deliberately excluded. Notification text and parsed records stayed on the device. Privacy rules were decided before adding convenience features because a budget app contains sensitive patterns of daily life.
Card-specific approval periods became the first hard problem
Adding transactions from the first to the last day of a month did not match actual card billing. Each card had its own approval window and payment schedule. I added separate period calculations and navigation to previous and next periods.
A transaction imported from an image and the same transaction received from a notification must be counted once. However, two legitimate purchases at the same merchant for the same amount must not be collapsed. The rules eventually considered source, issuer, approval period, time, and amount together. The summary and card detail screens were also changed to share the same calculation logic.
OCR filled the gap for older statements
Notification access is useful only for new notifications received after installation. To recover older history, I added an image importer for card statements and approval-history screenshots. The user selects the card issuer first, then Korean OCR runs on the device. Results are not saved until confirmation. Selecting another issuer clears the previous candidate so stale OCR data cannot appear under the wrong card.
Every issuer uses a different layout and wording, so parsing required several rounds of improvement: pairing dates and amounts by visual position, handling expanded menus that hide rows, and distinguishing cancellations from approvals.
Adding budgets and cash expenses
Card totals alone did not describe total household spending. The app reads an existing Google Sheets budget and imports both category totals and row-level details. Cash expenses are classified as fixed or one-time. Fixed items carry forward, while one-time items remain in their original month. Add, edit, and delete operations update the summary and monthly chart immediately.
The app eventually compared several months of card and cash spending and explained whether current spending was below or above the monthly budget.
Verification mattered more than prompting
AI accelerated implementation, but reliable financial totals still required precise definitions and human verification. Automated tests covered approval-period boundaries, notification parsing, OCR date-and-amount pairing, cross-source deduplication, preservation of legitimate repeats, recurring cash behavior, agreement between summary and detail screens, and reconciliation of row-level budgets with totals.
I created source backups before changes and repeated unit tests and APK installation checks afterward. A number that looks correct on one screen can still be based on a different rule elsewhere, so both the visible result and the calculation rule must be tested.
An app that evolved through use
The greatest benefit of vibe coding was not simply speed. It made daily needs immediately testable: cash should be included, fixed costs should continue next month, and each card should follow its own approval period.
The first AI-generated result could never be accepted blindly. Privacy boundaries, definitions of totals, duplicate handling, and regressions all needed repeated review. The useful product came from a cycle of small requirements, real-world errors, backups, tests, and verification—not from a magical prompt.
The result is not a universal finance product, but it has become a personal tool built around the workflow I actually need. Vibe coding works best not as a replacement for development, but as a powerful method when the user can explain the problem clearly and verify the outcome.