Budget.io

Context

Budget.io began as a personal and household budgeting product built around my own real financial workflow. Its purpose was not to claim broad consumer-finance demand; it was to make my own recurring decisions clearer and more reliable.

Problem

The important question was not simply, “How much did I spend this month?” A traditional monthly view felt too passive because it showed spending after it happened. The more useful question became, “How much can I safely spend this week?”

There was also a reliability problem: if money had already been spent but Plaid had not posted the transaction yet, Budget.io could incorrectly show that money as still available to spend.

Users and context

The primary user is me, using the product for a real household budgeting workflow. Budget.io is intentionally presented here as a personal product shaped by that workflow, not as a broad consumer-finance product with market-demand claims.

Constraints

• Plaid synchronization has request and cost constraints, so the dashboard moved away from automatic page-load sync toward stored transaction data with background, nightly, and manual synchronization paths.
• The product needed to account for future bills and savings before calculating available-to-spend money.
• Weekly cycles needed to remain intact across calendar-month boundaries while monthly reporting remained available for context.
• The frontend is a single-page application, and serverless environments are not a reliable home for scheduled jobs by themselves.

Product decision: weekly spending control

The product intentionally evolved toward weekly budgeting:

• Weekly allowance and safe-to-spend guidance answer the near-term decision.
• The pay-cycle start day is editable rather than fixed.
• A monthly outlook remains available for context and reporting.
• Future bills are reserved before available-to-spend money is calculated.
• Savings is separated from spendable money instead of being counted twice.
• A fifth paycheck behaves more like bonus savings than an expansion of normal weekly guardrails.

This model trades some calculation complexity for a clearer decision surface: the dashboard is designed to help decide what can be spent next, not only explain what already happened.

Prioritization decision: pending transactions before Splitwise automation

Two feature opportunities were considered:

1. Include pending Plaid transactions in the budget calculation.
2. Add bidirectional Splitwise synchronization.

Pending transactions were prioritized as part of the core budgeting reliability problem. A pending debit can change the answer to “what is safe to spend?” before the bank posts it. Splitwise was treated as a separate automation opportunity and implemented as a review-and-post flow; bidirectional synchronization is not implemented.

Implemented MVP scope

• Link and sync bank transactions through Plaid, with stored transaction data for normal dashboard loading.
• Process recurring transactions across configurable intervals.
• Calculate weekly safe-to-spend guidance while retaining a monthly outlook.
• Separate spent, reserved, saved, and available money through derived budget state.
• Include pending debits and reconcile them with their later posted successors.
• Filter payment and refund transactions that should not count as spending.
• Review and post eligible split transactions to Splitwise through a controlled proxy.

Technical approach

The frontend is a vanilla JavaScript single-page application. Supabase stores authentication, transaction data, state, history, and alert records. Plaid Link and transaction retrieval run through server-side and Supabase Edge Function paths. Vercel functions provide API routes, while an optional Express server provides an alternate runtime, webhook handling, and cron behavior. Resend delivers alerts, and Splitwise is accessed through an authenticated API proxy.

Tradeoffs

| Decision | Benefit | Tradeoff | | --- | --- | --- | | Weekly control with monthly context | Supports near-term spending decisions without losing reporting context | Requires two related budgeting views and date models | | Stored transactions plus nightly/manual sync | Reduces page-load requests and keeps the dashboard responsive | Freshness depends on sync timing unless the user triggers a manual sync | | Pending transactions in the core budget | Protects the safe-to-spend calculation from posting delays | Requires successor reconciliation to avoid counting one purchase twice | | Splitwise review-and-post flow | Adds useful shared-expense automation with an explicit review step | Does not provide bidirectional synchronization | | Hybrid serverless and Express scheduling | Supports scheduled work where serverless execution is limited | Adds deployment and runtime complexity |

Success metrics

Success would be measured by one core outcome: whether Budget.io helps users make better weekly spending decisions. Supporting measures could include safe-to-spend accuracy during pending-to-posted transitions, sync freshness, and the time required to answer the weekly spending question.

Results

The result is a working budgeting product that models paycheck cycles, reserves future bills, separates savings from available money, includes pending debits, and stores transactions between syncs. Its strongest outcome is a clearer weekly decision surface built around safe-to-spend guidance.

Iteration and learning

The implementation history shows the budgeting model becoming more specific over time: monthly reporting was retained, while spending control moved to paycheck cycles; reserve accounting was separated from expenses; pending transactions were added to protect the core availability calculation; and Splitwise became a separate review workflow.

The central product lesson was that the budgeting model should follow the decision the user is trying to make. For this workflow, that decision is weekly safe-to-spend guidance, with monthly reporting serving as context rather than the primary control surface.

What I would do next

I’d first define success around one core outcome: whether Budget.io helps users make better weekly spending decisions. From there, I’d validate which direction creates more value — deeper household automation or a broader consumer budgeting experience.