Had a focused session today expanding the goal system design for Pezeta. Yesterday I started with the basic concept, today I dove deeper into the details.

I expanded all four goal types with detailed logic and edge cases:

• Someday goals are your classic piggy bank. You want $3,000 for a new laptop someday. The system suggests funding it until you hit that target, then stops.
  • Edge case: what happens if you change the target from $3,000 to $4,000? Only future months use the new target.
• Monthly goals keep a set amount available each month. You want $200 available for groceries each month. If you spend $150, you need $50 to top back up. If you somehow end up with $300, that’s fine – surplus is allowed.
  • Edge case: what happens if you never spend anything? The surplus just sits there – no more funding needed.
• Deadline goals add time pressure. $2,000 for a vacation by next summer. The system calculates: you need $200 per month to hit that target.
  • Edge case: what happens if you miss a month? The next month’s allocation jumps to catch up.
• Reserve goals are your safety nets. Keep at least $2,000 in emergency savings. If it dips to $1,500, fund $500 immediately.
  • Edge case: what happens if you never touch it? No allocation needed – it’s already above the reserve.

So this session was used to think about these and take a deep dive in the goal rule engine inner workings. I still have questions but it will be iterated when I start using the MVP. I have goal examples in my current budget for all of these.

The technical challenge was handling goal changes over time. What happens if you change your vacation target from $2,000 to $3,000 in March? Should January’s allocation be recalculated as if you always wanted $3,000?

I went with a snapshot approach. Each month gets its own snapshot of goal parameters. Past months never change retroactively. January’s allocation was based on January’s goal settings, period. This preserves the audit trail of what you were thinking at the time.

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.