2025.07.17.

Pezeta Progress Log

Spent today designing the Rails controller layer for Pezeta.

I analyzed Capito, an envelope budgeting prototype I built seven years ago. Standard approach – categories as envelopes, track balances, show what’s left to spend, like YNAB. But Pezeta takes a different angle. Instead of manually managing category balances, I’m building a goal-oriented system where users define financial objectives and the system calculates the monthly allocations needed to achieve them.

For the controller architecture I designed five main tasks:

Authentication & Ledger Foundation – Auto-create ledgers with system categories when users sign in the first time. System categories like Income and Safe to Spend get created automatically, so no manual setup required.

Budget Controller – Returns a single JSON endpoint for now, focused on Safe to Spend calculation and future goal balances. This is what the UI will display prominently, not a list of category balances.

Categories Controller – Standard CRUD for user-defined categories. Goals are implemented as special categories with allocation rules that determine how they get funded each month.

Monthly Allocations – This is where goal-driven allocations get applied, but users can override them when needed.

Test Infrastructure – Rails conventions with fixtures that include the system categories.

I’m sticking with pure Rails MVC patterns, so no service objects, no complex abstractions. Business logic lives in models, controllers stay thin, everything renders JSON for now since we don’t have a Turbo-based UI yet.

This foundation should make the goal system feel automatic rather than manual.

2025.07.15.

Pezeta Progress Log: Day 9

I built the model layer for goal-oriented budgeting in Pezeta today. This is the implementation of the goal system I’ve been designing over the past week.

I’ve laid the foundation for four distinct goal types:

  • Someday Goals – For big purchases. Save until you hit your target amount, then stop allocating.
  • Monthly Goals – For recurring commitments. Allocate a fixed amount every month, like subscriptions or regular savings habits.
  • Deadline Goals – For time-bound expenses. Spread the target amount evenly across the remaining months until your due date.
  • Reserve Goals – For emergency funds. Maintain a buffer of N months of average expenses based on your actual spending patterns.

I still need to test all of this thoroughly, but the models are in place and the calculations are working. What I like about this approach is how it will turn vague financial intentions into concrete monthly actions. Want to save $5,000 for a vacation by next December? The system can calculate exactly how much to set aside each month. Need three months of expenses in your emergency fund? It’ll figure out what that means based on your actual spending patterns. The system tracks progress over time, adjusts recommendations based on current balances, and integrates smoothly with the existing budget structure.

Next up is building the UI layer. The foundation is solid, but there’s still work to do before I can actually use these goal features in my own budgeting workflow.

2025.07.11.

Pezeta Progress Log: Day 5

Today I worked on planning Pezeta’s goal system. I experimented with using two AI agents to collaborate on breaking down the work: Claude Opus 4 as the coordinating agent with read/write access, and ChatGPT o3 through Repo Prompt for implementation planning.

The idea was to leverage each model’s strengths. Claude handles the file operations and manages the task structure, while ChatGPT analyzes the codebase and suggests implementation approaches. They literally chat with each other using the Repo Prompt MCP tool, with Claude asking questions and ChatGPT providing analysis. Sometimes I had to intervene to guide them back on track or stop them to wait for my approval on design decisions. It’s like having two developers pair programming, each bringing their own expertise to the planning session.

The approach surfaced some important design decisions. Instead of service objects, we’re going with Rails-idiomatic patterns: model methods, class methods on MonthlyAllocation, and callbacks for snapshots. Everything through ActiveRecord.

Planning Through Test Cases

The bulk of the work went into defining test specifications:

  • 7 test cases for SomedayGoal
  • 15 for MonthlyGoal (including top-up logic)
  • 17 for DeadlineGoal (with auto-advance scenarios)
  • 17 for ReserveGoal

Each test case addresses specific edge cases. What happens when a monthly goal already has surplus funds? How does a deadline goal behave when it’s past due? Getting these details right upfront matters.

All calculations will use “opening balance,” the balance at the start of the month, not the current balance. This prevents allocation amounts from changing as transactions flow through during the month, which matches how people think about budgets.

The session produced seven detailed task files ready for implementation. Each includes exact specifications, test cases, and implementation notes. The tasks cover Single Table Inheritance strategy, historical snapshots through callbacks, and model-driven allocation suggestions.

Tomorrow I’m letting Claude Code implement these tasks.

2025.07.10.

Pezeta Progress Log: Day 4

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.

2025.07.09.

Pezeta Progress Log: Day 3

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.

2025.07.08.

Pezeta Progress Log: Day 2

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.

2025.07.07.

Starting Pezeta

Finally decided to start building Pezeta today. It’s been in my mind for years – since we started Agyvihar, our Hungarian podcast about personal finance and productivity.

What’s Pezeta?

Simple: a budgeting app that tells you one number – how much you can spend right now.

That’s it.

No charts. No categories. No endless reports. Just open the app and see: $47. Or $134. Or whatever you can actually spend without screwing up your budget.

The features (keeping it minimal)

The One Number – Your daily spending limit. Updated in real-time. Factors in your bills, savings, everything.

Goals – Want to save $2000 by December? Cool. The app adjusts your daily number automatically. No spreadsheets required.

That’s basically it. If budgeting were simpler, maybe more people would actually do it.

Starting with Rails

I’m not jumping straight into building native apps. Starting with a Rails MVP instead.

Few reasons:

  • Rails 8 has some new stuff I want to try
  • Need a reference implementation anyway for the iOS/macOS versions
  • I can actually use it myself while building

This Rails version won’t go public. It’s just for me to validate the idea and work out the kinks.

Building in public (might regret this)

I’m putting it all out there because watching someone figure things out might be more useful than another perfect tutorial.

Partly for feedback – maybe someone will tell me this is a terrible idea before I waste six months on it.

Partly for accountability – harder to quit when people are watching.

Partly because I’m curious what happens when you share the messy process instead of just the polished result.

The plan

Starting with Rails 8 setup, basic models, authentication. The boring foundation stuff that nobody talks about but takes forever.

After that, we’ll see. Building software is weird.