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.

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.

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.