Today wrapped up the core data foundation with the Budget view model and spent time planning the goal allocation rules that’ll make this budgeting app different.

The aggregation layer

The Budget model pulls everything together. Give it a ledger and a month, and it calculates the current state of all categories, their allocated amounts, actual spending, and remaining balances.

This is just pure Ruby class that takes the foundational models and presents them in a way that makes sense to users.

Goal allocation rules

The bigger breakthrough today was finalizing the goal allocation rules. This is what’ll set Pezeta apart from traditional envelope budgeting.

Instead of managing dozens of budget categories, users define their financial goals—things they actually care about saving for. The app figures out how much to allocate to each goal and shows one simple number: how much is safe to spend on everything else. Goals run in the background while you focus on that single “Safe to Spend” amount.

I want to implement four goal types:

• Someday: Save for something with no deadline—like a new laptop or vacation fund. Allocates the difference between target and current balance until you hit the goal.
• Monthly: Keep a certain amount available each month—like rent or groceries. Tops up to the monthly amount, and any surplus stays there.
• Deadline: Gather a lump sum by a specific date—like saving $3000 for a trip by July. Calculates how much to save each month based on time remaining.
• Reserve: Maintain a minimum balance at all times—like an emergency fund. Only allocates money when the balance dips below the reserve amount.

Each follows different allocation formulas, but the key insight is the engine just calculates expected allocations—it never moves money automatically. That stays under your control.

The vision coming together

I’ve got a React prototype artifact built with Claude that demonstrates how this will look. We have a simple “Safe to Spend” number on top, goals running quietly in the background. I just created this to validate the UX approach, but it shows the vision clearly.

Day two of building Pezeta. Yesterday was all planning and starting. Today was about getting my hands dirty with actual Rails models.

Completed the three core models today:

• Category model (with proper enums and validations)
• MonthlyAllocation model (with decimal precision for money)
• Transaction model (income/expense tracking)

Not the most exicting part for people to see (and I’m spending about 1–2 hours a day to build this), but I want to get the models right, that’s the whole point of why I’m writing the first MVP in Rails, I know Rails the best.

I’m trying to stick to test-driven development. Write the test first, make it pass, move on. Feels slower at first, but every time I change something, I know immediately if I broke anything.

The workflow experiment

Here’s something weird I’m trying: I started a new zettelkasten in Obsidian yesterday to drive this whole project.

The idea: use notes as the driving force to guide Claude Code through writing the actual code. I think in the zettelkasten, then I let AI collect that context and draft the output: code, blog posts, status updates etc. At the end I still manually review and adjust.

I’m using a modified version of Ian Nuttal’s Task Magic system to drive the development. Break big plans into smaller tasks, then automate the output generation. Not just code generation though. Claude Code helps with everything like documentation, tests, even these blog posts, but I’m still reviewing everything.

My theory is that this might be the fastest way to do solo development today. Capitalize on what AI is actually good at – turning clear thinking into working artifacts.

We’ll see if this scales. but for now, it’s working.