PocketWatch

Inspiration

Your bank balance tells you what you have right now. It doesn't tell you what that new laptop means three weeks from now, after rent clears, your subscriptions renew, and your next paycheck is still a few days out. Most of us just guess. We wanted to replace that guess with something better, so we built PocketWatch. You ask "Can I afford this?" and instead of a flat yes or no, it shows you the range of ways the next two years could actually play out.

What it does

You ask PocketWatch a money question in plain English, either on the website or over iMessage. It builds a model of your cashflow from your transaction history, applies the decision you're thinking about, and runs 500 simulated futures over the next two years. Then it compares those futures to doing nothing, tells you how often your balance dips below zero, and points to the recurring bill pushing you closest to the edge.

It handles a lot more than "can I buy this one thing":

Income changes like a raise, a bonus, or a new job. If you give a salary, it converts it to take-home pay first.
Loans and mortgages. The payments are calculated in code, and if you're buying a home, your rent stops.
Multiple purchases in the same question.
"When could I afford it?" If now is too risky, it finds the earliest week where your chance of going negative drops to 10% or less.
Financing. If paying upfront is risky, it tries different loan lengths at your own interest rate and tells you which ones would keep you above water.
Spending audits. Ask "Where can I cut back?" and it ranks your optional subscriptions by how much you'd save by dropping them.
Habit costs. "What does a $7 coffee three times a week cost me in a year?"

Every answer comes with a link to a replay page. There you can see the full spread of outcomes, the assumptions the model made, and the exact transactions behind every number.

All of our data comes from synthetic customer profiles in Capital One's Nessie API. The results show what happens under the model's assumptions, so treat them as a guide and not a promise about anyone's future.

How we built it

We split the work into four pieces: the simulation engine, the data and API layer, the language layer, and the interfaces people actually use.

The simulation is written in Python with NumPy. It steps forward one week at a time and uses a fixed random seed, so any run can be reproduced exactly. We draw all the randomness once and reuse it everywhere. That means when we compare "buy it" against "don't buy it," or remove one bill at a time to see which one matters most, the only thing that changes is the decision itself. Luck doesn't sneak into the comparison.

The data and API layer runs on FastAPI. We pull records from Nessie, cache them locally, figure out each person's pay schedule and recurring bills, and keep every transaction ID as evidence. Each run gets saved to SQLite along with the exact inputs that produced it, so you can come back later and replay it. Supabase handles sign-in and stores the assumptions we might want to tweak, like each person's tax rate and loan rates.

The language layer uses Gemini, but we kept it on a short leash. Gemini reads your question and fills in a structured form, and our code does all of the math. If your question has a number we can't account for, PocketWatch asks you to rephrase instead of guessing. Gemini also writes the final explanation, but only from a list of facts our simulation produced, and a checker rejects any number that didn't come from that list. If the explanation fails the check, we use a plain template instead. There's also a rule-based parser, so the whole thing still works with no API key at all.

The interfaces are a Next.js web app designed to look like a Windows XP desktop (complete with sign-in and draggable windows) and an iMessage agent built on Photon Spectrum. The web app's replay pages show percentile bands, a week-by-week slider, and clickable evidence. The iMessage agent texts you back the answer, a replay link, and images of the chart and key stats.

How to use

At https://www.pocketwatch.tech/, log in to one of the Nessie API accounts, in which the passwords are the names-aero (for Jordan, it is jordan-aero). From there, you will be able to access the feature to test what Jordan (or any other user) can purchase with historical data used to simulate future possibilities.

Challenges we ran into

The biggest one was getting the data into a state we could trust before simulating anything. Some API resources were missing, some merchant references pointed to records that no longer existed, pay schedules weren't always regular, and we had to settle on one consistent rule for dollars versus cents. Keeping the original evidence around turned out to be really important, because it let us tell the difference between "this data is missing" and "this person really didn't have any transactions."

The second was keeping the explanations honest. Language models love to make up numbers, so we designed the whole response around structured facts, a checker, and a fallback. Parsing questions was hard in the opposite direction. Something like "I'm taking a $90k job and want to buy a $400k house with 10% down" has a bunch of numbers that each need to end up in the right place. We decided it was better to ask the user to rephrase than to quietly drop one of them.

Accomplishments that we're proud of

Every saved run can be reproduced exactly, down to the inputs and evidence behind it.
We went way past a yes or no score. PocketWatch compares scenarios, names the bill driving your risk, suggests a safer time to buy, and lays out financing options.
The same backend powers both the website and the iMessage agent.
We have 622 passing automated tests, plus documented checks across six synthetic customers, including making sure every piece of evidence resolves and saved runs survive a restart.

What we learned

Data quality, units, and timing matter just as much as the simulation does. A probability is only useful if you know the assumptions behind it and can trace it back to real evidence. Keeping the math completely separate from the language model made the whole system way easier to test, and way easier to trust.

What's next for PocketWatch

Calibrate the model against real transaction histories, not just synthetic ones
Do a better job explaining uncertainty on the replay page
Move saved runs from SQLite to the Postgres tables we've already set up in Supabase
Pull in each user's real loan rates from their bank instead of using typical rates
Test with a much wider range of spending habits and life events