Start here / one concrete request
“Will this financed purchase be paid off before the promotional deadline, and what should we check next?”
Synthetic example: a $200 payment recently posted, $600 remains, and the checked deadline is three weeks away. Morgan and Lee want to check the payoff before that deadline. All names and amounts are illustrative.
A published snapshot shows the dated obligation, conditional plan, cash-pressure estimate, and review actions. The household verifies funding and payment outside the app, then returns evidence for the next cycle.
From request to result
What happens next
-
Start the review
The operator starts a refresh for Morgan and Lee so their next decision uses newer bank information. The account service, Monarch Money, supplies balances and payment history without changing anything at the bank. If they also bring a new statement, a person checks its terms before changing the saved deadline.
What moves forwardThe latest bank information and checked deadline move into the review.
How this step works
A refresh reads what Monarch currently reports; it does not necessarily ask every underlying bank to resync. New statement evidence follows a separate path when supplied. AI may propose extracted terms, but meaningful record changes require human review. Previously accepted terms carry forward, so a new statement is not required on every refresh.
-
Save the latest bank picture
Finances saves the retrieved information privately and records when it arrived. The history may now include Morgan and Lee’s $200 payment, alongside the latest reported balance. It also asks for upcoming bills and expected deposits. Keeping these sources dated lets the next step distinguish a new observation from an older checked figure.
What moves forwardThe dated bank picture is ready to compare with the saved payoff terms.
How this step works
The bank balance can lag settlement, even when the payment appears in history. The upcoming calendar is a separate source of recurring items and synced liability statements; receiving it does not establish complete bill coverage. Noncritical source failures are recorded. Missing forecast inputs can disable the cash estimate while other retrieved information remains usable.
-
Check what changed
The calculation engine compares the new bank picture with the checked payoff record. It keeps the $200 repayment separate from purchases, so it does not count the payment as new spending. If the reported balance supports $600 remaining, the picture agrees. If the figures disagree, the difference stays visible for someone to resolve.
What moves forwardThe calculations receive the remaining obligation, its deadline, and any open disagreement.
How this step works
Source identities help prevent duplicated feed records from becoming duplicated spending. An unlinked obligation keeps a labeled last-verified or estimated balance. Reported balance differences remain visible; a tracker-owned deadline that disagrees with accepted plan records blocks the plan build until reconciled. These checks preserve the distinction between a bank observation and a confirmed financial term.
-
Work out the deadline and cash pressure
The engine asks two related questions: will the observed payment pattern cover the $600 before the deadline, and what pressure will that obligation put on cash? It combines checked terms with the accepted plan, then estimates income, spending, and other payments. A projected payoff is still a plan until evidence shows it happened.
What moves forwardThe household gets a payoff timeline and a separate cash-cushion estimate.
How this step works
The plan branch calculates milestones and conditional actions from accepted records; it does not schedule payment. The cash branch reserves existing balances on cards paid in full, adds estimated income, and subtracts future spending, other payments, and remaining promotional payoff requirements. Previously counted minimum payments are not deducted again. Purchases and their later card payments are not double-counted either. The cushion considers low points before paychecks, suppresses missing material inputs, and remains a planning estimate rather than an exact balance or safe-to-spend amount.
-
Choose what needs attention
The engine turns the timeline and cash picture into review actions. For Morgan and Lee, checking the remaining payoff and its funding belongs in that review. Rules weigh urgency, evidence, and the approaching deadline; optional AI assistance can suggest further questions. The household’s stated priority is avoiding interest and missed deadlines before chasing extra rewards.
What moves forwardThe review actions are ready to appear alongside the plan.
How this step works
The exact rank depends on the other current signals, including severity and value. Separate branches produce an existing-card purchase guide and, when enabled, advisory public-offer headlines; neither changes the payoff obligation. Without model access, deterministic review outputs remain and skipped advisory dimensions are identified. Accepted plan numbers are recalculated by code without a new AI extraction call.
-
Send the updated picture to the phone
The operator publishes the prepared plan, cash view, and review actions to the private phone website. Morgan and Lee can now read the dated $600 obligation there. The normal publication path checks for a recent bank pull and verifies the new site build. Refreshing alone prepares the information; publishing makes it available on the phone.
What moves forwardThe phone can read the new snapshot, with its bank-data date visible.
How this step works
The website uses SvelteKit pages hosted on Vercel to serve a saved private data bundle. Raw transaction rows stay local. Weekly review does not publish by default. Normal publication requires a Monarch pull no more than 24 hours old, but an explicit override can publish the current bundle. Reloading the phone page does not fetch Monarch data; rebuilding the site does not advance the original source date.
-
Act and bring back proof
Morgan opens the shared view and sees the payoff plan, cash estimate, and next checks; Lee can read the same picture. Morgan verifies the payoff with the issuer and makes any payment outside Finances. Evidence of completion then returns through the maintained review process, so the next update can reflect what actually happened.
What moves forwardNew evidence and the next bank pull begin another cycle.
How this step works
The home view includes bills ahead, the payoff table, milestones, and checklists; the weekly brief provides review actions. Old-data warnings remain visible. A phone checkmark saves only on that phone: it does not update accepted records or appear on the other phone. Substantive completion requires who confirmed it and supporting evidence. Passing an expected date can make an action overdue, never complete.
The system behind the story
Every piece has a job
Open a piece for its role, or a technology for the choice and tradeoff.
PeopleThe household and operator
Supply evidence, accept meaningful changes, start refreshes, and take real-world actions.
ServiceBank information — Monarch Money
Supplies connected-account balances, transactions, and reported upcoming items through read-only retrieval.
RecordsChecked trackers and accepted plan records
Preserve terms, source references, labeled assumptions, and evidence of completed actions.
SoftwareCalculations — Python engine
Reconciles sources and computes dates, projections, cash estimates, and action priorities.
ServiceOptional AI assistance
Proposes document terms or account matches and adds advisory judgment; it does not directly confirm financial facts.
SoftwarePhone view — SvelteKit on Vercel
Presents the private published snapshot. The phone reads it; the local workflow refreshes and publishes it.
Why these technologies?
Bank information — Monarch Money
- The job
- Provides balances, transaction history, and reported upcoming items.
- Why this choice
- It is the existing connected-account source. Checked statement evidence supplies important terms alongside it.
- The tradeoff
- A failed connection stops new bank observations. Synchronization can lag, and a forecast can omit bills; a successful export does not establish complete coverage.
Calculations — Python and checked records
- The job
- Compute repeatable arithmetic and dates from accepted facts and labeled assumptions, with source checks.
- Why this choice
- The repository explicitly assigns financial arithmetic to code and meaningful record changes to human review. No language-selection rationale was established.
- The tradeoff
- The records need maintenance. Missing evidence or contradictory tracker deadlines can block a build rather than producing a reassuring guess.
Optional interpretation — AI through OpenRouter
- The job
- Connect configured models for document extraction proposals, advisory critique, and optional relevance tagging.
- Why this choice
- The documented gateway supports configurable models while keeping arithmetic in the calculation engine.
- The tradeoff
- Advisory features depend on model access and send selected caller-supplied text or metadata. Proposals need review; raw Monarch transaction rows do not enter this model interface.
Snapshot delivery — a private data bundle
- The job
- Package selected derived information into each published build instead of querying a live financial database from the phone.
- Why this choice
- The documented architecture keeps maintained local records as the source of truth and raw transaction rows off the hosted app.
- The tradeoff
- New bank data needs both a working local refresh and a new publication. If the local machine or scheduling app is unavailable, the existing view ages.
Phone pages and hosting — SvelteKit and Vercel
- The job
- Render the pages and host the private published website, with a home-screen installation manifest.
- Why this choice
- These are the current page and hosting technologies. A specific framework or hosting selection rationale was not established.
- The tradeoff
- Installation does not establish offline access. No service worker or push subscription-and-sender path was found in the inspected web source.
Phone checkmarks — browser local storage
- The job
- Remember checklist ticks and answers in the browser on the device used.
- Why this choice
- The source identifies this as interim per-phone persistence while shared state remains undecided.
- The tradeoff
- Ticks do not sync across phones or update accepted plan records. A convenient checkmark is separate from an evidence-backed completion.
Keep the boundary clear
What exists, and what comes next
The private tool presents a forward plan, bills ahead, and review actions. Bank updates reach the phone through a new published snapshot; shared checkmarks and deadline notifications are still planned.
Implemented today
- Current source implements read-only retrieval, private raw evidence, reconciliation, accepted structured plan records, and deterministic plan calculations.
- The shared home view renders a payoff table, forward milestones, checklists, cash and bills ahead, and a guarded cash-cushion estimate.
- The bundle includes ranked review actions, optional AI assistance, and an existing-card purchase guide. Phone ticks persist on the device used.
- Normal publication checks source freshness and verifies the new hosted build; the website reads the published snapshot.
Limits of the current system
- The cushion is a liability-adjusted planning estimate. The source calendar remains incomplete, and exact available reserves remain unresolved.
- Shared phone confirmations and Android deadline notifications are not implemented in the inspected source. Offline access was not established.
- The hosted build, current account and model access, successful scheduled refreshes, and real-device behavior were not checked in this read-only inspection.
- The one-minute answer is an intended outcome, not a measured result. This operator-maintained private tool does not establish self-service onboarding for other households.
Next, not yet established
- Durable completion state shared across both phones.
- Android deadline delivery, with the delivery mechanism still an open decision.
- Improvements that reliably achieve the intended quick answer: where the household stands, what changes next, and what to do.
Say it back
The version to remember
Finances turns bank observations and checked financial terms into a forward household plan. We read Monarch without changing it, keep original transactions private, and let code calculate deadlines and cash estimates. AI can help interpret evidence, but people confirm meaningful changes. The phone reads a published snapshot showing the plan, bills ahead, and actions to review. Reloading does not refresh bank data. Payments happen outside the app, and completion needs evidence; phone checkmarks still stay on one device.
Founder questions
Check your understanding
Is it a budgeting dashboard or a planning tool?
Its main job is the forward plan: what must happen next and what needs attention. Spending history supports that plan and its estimates.
Does it move money or pay bills?
No. It reads bank data and presents information. The household takes payment and other real-world actions outside the app.
How do you prevent AI from making up a financial answer?
Accepted records and deterministic calculations own authoritative plan numbers. AI proposes or critiques; meaningful changes are reviewed. Source conflicts and missing inputs remain visible.
Why is the bank balance different from available cash?
Existing card obligations, upcoming payments, planned spending, and timing affect it. The cushion accounts for these through explicit estimates; it does not claim an exact safe-to-spend amount.
How current is the phone view?
It is as current as the last published source snapshot. The view shows age and warnings. Reloading does not fetch bank data; normal publication requires a recent pull.
Can two people coordinate from their phones?
They can read the same published view. Checkmarks currently persist only on the phone used. Shared confirmations and deadline notifications remain future work.
What is proven today?
The described code paths and page wiring exist. Live delivery, current access, successful schedules, and the one-minute user outcome were not verified in this inspection.