I defined the product behavior, designed the interface and budgeting logic, and built a functioning static web application with local persistence and offline support.
Working Browser Application
SOMA Budget Planner
A private-by-design monthly budgeting and scenario-planning application that turns editable income and expense data into clear budget status, spending pace, daily guidance, projections, and portable backups.
The work at a glance
Use the live application, change the sample budget, switch months, test spending pace, then inspect the public source code.
The current release stores information in the browser only. It has no account system, cloud synchronization, bank connection, or server-side financial-data storage.
Working proof
Not a mockup. A usable application.
The product problem
A monthly budget should answer more than “how much did I spend?”
Traditional budget tables show planned and actual amounts, but they often leave the user to interpret whether current spending is sustainable. SOMA adds an operating layer: how much flexible budget remains, how many days remain in the month, what daily spending level is still available, and what the month-end position could look like if the current pace continues.
The interface is deliberately editable and reversible. Categories, expense items, budget amounts, actual amounts, spending types, and months can all be changed without requiring an account or sending the data elsewhere.
Decision support
The application translates raw entries into an operating view.
Each edit recalculates the monthly position. The dashboard compares income, planned expenses, actual spending, remaining income, and planned balance, then adds calendar-aware guidance for flexible spending.
Implemented now
- Editable income, categories, items, budgets, and actual spending
- Fixed and flexible category classification
- Month switching and copy-forward planning
- Budget-versus-actual category variance
- Overall budget-used visualization
- Days remaining, flexible budget left, and safe daily spending
- Projected month-end balance based on current flexible-spending pace
- JSON backup and import, CSV history export, and print view
- Dark mode, keyboard navigation, responsive layout, and offline support
Monthly position
Budget status at a glance
Net income
Current monthly plan
Current monthly plan
$4,800
InputFlexible budget left
Budget minus actual flexible spending
Budget minus actual flexible spending
$620
AvailableSafe to spend daily
Remaining flexible budget ÷ days remaining
Remaining flexible budget ÷ days remaining
$47
GuidanceProjected month end
Income minus fixed expectation and projected flexible pace
Income minus fixed expectation and projected flexible pace
$310
ProjectionCalculation logic
Useful guidance built from inspectable rules.
The application uses deterministic calculations. There is no hidden model generating financial advice.
Plan
Enter monthly income and budget amounts for fixed and flexible categories.
Record
Add actual spending as the month progresses.
Compare
Calculate planned-versus-actual totals and category variance.
Adjust for time
Compare flexible-spending progress with the percentage of the month elapsed.
Project
Estimate a month-end position using fixed obligations and the current flexible-spending pace.
Architecture
Intentionally small, portable, and inspectable.
The first release avoids unnecessary infrastructure so the core budgeting behavior can be tested before adding synchronization or integrations.
Current application architectureNo backend required
HTML interfaceSemantic form controls, templates, summaries, and dialogs
JavaScript stateMonthly budgets, calculation logic, validation, import, export, and UI updates
Browser storageVersioned local data model with migration from the earlier storage format
PWA layerWeb manifest and service worker for installability and offline access
Implementation evidence
Product decisions are visible in the code.
The public repository makes the application behavior inspectable rather than asking a reviewer to rely on screenshots alone.
| Area | Implemented evidence | Why it matters |
|---|---|---|
| Data model | Versioned store with up to 240 month records, normalized categories and items, and migration from the earlier local format | Shows state design and backward-compatible thinking |
| Planning | Copy-forward duplicates the prior plan with fresh identifiers while resetting actual spending to zero | Preserves a usable monthly workflow instead of copying stale actuals |
| Decision support | Flexible-spending pace, daily available spending, calendar progress, and projected month-end balance | Turns entries into actionable context |
| Input safety | Numeric amounts are normalized to nonnegative values; imported data is validated and size-limited | Reduces malformed local state and unsafe assumptions |
| Portability | JSON backup and restore plus CSV history export | Gives the user control over local data and reduces browser lock-in |
| Accessibility | Semantic labels, live status announcements, keyboard movement between amount fields, responsive layouts, and print support | Makes routine use more practical across input methods and devices |
Selected design decisions
Build the smallest useful system before adding infrastructure.
- Local first: prove the budgeting workflow without requiring users to create an account or send private financial entries to a backend.
- Separate plan from actual: copying a month carries forward structure and budget amounts but intentionally resets actual spending.
- Make the calendar part of the calculation: spending pace is more useful when compared with how much of the month has elapsed.
- Keep the projection explainable: month-end guidance is derived from fixed expectations and observed flexible spending, not a black-box prediction.
- Design an exit: backup, import, CSV export, and print reduce dependence on one browser session.
What this demonstrates
I can move from an operational problem to a working tool.
SOMA complements my enterprise implementation work. The SFPUC case shows how I operate inside a large controlled environment. SOMA shows that I can independently define requirements, model the workflow, implement the logic, design the user experience, and publish software another person can actually use.
Current maturity and limits
SOMA Budget Planner is a working static web application and an applied product case study, not a banking product or personalized financial-advice service. It does not connect to financial institutions, move money, synchronize across devices, authenticate users, or store data on a server. A companion spreadsheet and optional synchronization are potential future extensions after the core interaction model is validated.