Building BudgetMuna: connecting cards, budgets, and accounting

Start with the next payday

“Budget muna, bago swipe” gives the product a concrete job: help someone plan before the next purchase. A person should be able to see which bills are approaching, what is building up on their cards, and how much they have assigned to everyday needs.

That makes the starting point smaller than a complete financial plan. Add a card, record spending, or set up a few envelopes. The product needs to make those first steps useful before asking someone to organize their entire money life.

A card is more than an outstanding balance

An outstanding balance alone does not describe a card’s payment cycle. Cut-off dates determine what belongs on a statement; due dates determine when a payment is expected. Installments add a schedule, and partial payments leave amounts to carry forward.

BudgetMuna makes these relationships visible through its statement and payment tools. It also groups cards that share a credit line, so the available limit is understood across the group rather than treated as independent room on each card.

• Statements follow each card’s cut-off and due dates.
• Installment tracking shows monthly shares and how many remain.
• Recorded payments link to the statement they were for.
• Shared limits give grouped cards a common view of available credit.

Envelopes describe the plan for money

Money in an account may already have several jobs. Some covers groceries, some covers rent, and some is being saved for a future goal. Envelopes make that intention explicit without moving money between bank accounts.

In BudgetMuna, income begins in Ready to Allocate. Users assign it to envelopes that refill monthly, aim for a target balance, or build toward a savings goal. Unspent amounts remain available across months. An overspending warning gives the user a reason to review the plan.

The distinction matters in the interface: allocating money is a planning action, while recording a purchase describes something that happened. Both belong in the product, but they should not be confused.

Keep purchases and payments from becoming two expenses

A simplified example shows why the accounting underneath matters. Suppose someone buys ₱2,000 of groceries on a credit card. The expense has happened, and the amount owed on the card has increased. Their bank balance has not changed yet.

When they later pay that ₱2,000 from a bank account, their bank balance and card liability both decrease. That payment settles the earlier purchase; counting it as another grocery expense would count the same spending twice. Interest and fees, if present, are separate items.

BudgetMuna’s public product model uses double-entry records: each transaction posts to two accounts, and balances, net worth, the balance sheet, and income statement draw from those records. The example illustrates the accounting relationship, rather than every posting rule or payment scenario in the app.

Make review part of the workflow

Receipt scanning is useful when it saves typing while leaving the user able to check the result. BudgetMuna presents itemized expenses for review before approval. The scan supports a decision instead of silently becoming the final record.

The same expectation applies to launch communication. The public site separates available tools from coming-soon features such as loan tracking, cash-flow planning, and statement reconciliation. A roadmap helps explain the direction, but users need to know which workflows they can use today.

Preparing for launch

BudgetMuna is preparing for launch, with early access available through its public site. It is a planning and record-keeping tool: it does not connect to bank credentials or move money. The portfolio screenshots use fictional sample data.

The principle I want to carry through the product is simple: show how a purchase, a payment, and an allocation affect the picture, then make the next step clear. Accurate records and understandable planning need to work together for that to happen.