Start with capacity, not history.
Transactions matter, but they do not answer the next decision. The interface leads with what is safe, what is committed, and what changes if the user spends now.
Back to worksProjected 
02.03.01 — tare.money
Narrative draft2025 · Budgeting prototype
tare.money
The useful question is not what is in the account. It is what can be spent without creating a future problem.
Role
Product framing, experience model, risk definition, and prototype critique.
Audience
People juggling recurring bills, discretionary spend, and credit-card payoff timing without a clear model of what is safe to spend.
Spending room
$1,240
Committed bills72%
Safe discretionary42%
Credit exposure28%
Guardrail
Spending on credit changes next month's capacity.
Primary artifact
Spending capacity model
Live artifact: tare.money frames the product around true discretionary balance, not account balance alone.
01 — Context
What this is really about.
Tare explores a common budgeting failure: people see a balance, forget what is already committed, and make a decision that looks affordable only in the moment. The prototype treats spending capacity as the primary object: committed bills, discretionary room, and credit exposure in one view.
Product Question
Can the experience make safe spending capacity clear enough to change behavior before the user overcommits?
02 — Problem
The user pressure.
Most personal finance tools explain the past. They show transactions, categories, or balances. The harder user need is forward-looking: what happens if I spend now, pay this bill on credit, or carry part of the balance into next month?
03 — Evidence
What the artifacts prove.
Public promise
The promise is specific enough to test.
The landing page tells users to stop guessing what they can spend. The prototype can be judged against that standard.
Model
Capacity has to be the main object.
A useful artifact separates committed bills, discretionary room, and credit exposure while still making them feel like one decision.
Risk
Credit needs a visible cost.
Bill-payment leverage has to show repayment timing and the consequence of carrying debt. The strongest state is one where the product warns the user instead of encouraging spend.
04 — Product Judgment
Product decisions.
Treat credit as a scenario.
Credit-card bill payment can help timing, but only when framed as a tradeoff with exposure and repayment assumptions.
Let the product say no.
Trust comes from constraint. Warnings, thresholds, and plain-language consequences are part of the experience, not compliance decoration.
05 — Evidence Plan
What is still missing.
Capture the prototype with sample data loaded: capacity view, bill calendar, a credit scenario, and one state where the product warns the user instead of encouraging spend.
Landing page screenshotCapacity meterBill calendarCredit payoff scenarioGuardrail states
Open Questions
01
What inputs does the user need to provide before the capacity model becomes useful?
02
Where does the product explain uncertainty in the projection?
03
What is the responsible default when credit-card leverage looks mathematically useful but behaviorally risky?