NexMove

Inspiration

When a lease ends or a car payment starts to hurt, Toyota customers face complex finance decisions alone. Most call support or take whatever the dealer offers. We wanted every Toyota Financial Services customer to see their real options, ranked, on one screen.

What it does

NexMove prices every option a customer has (lease buyout, prepaying extra miles and re-leasing, returning the car, trading in for an upgrade, refinancing, or keeping the car) and ranks them for that customer.

Affordability guardrails: an option is never recommended if the payment would exceed 15% of income, add more than half of the monthly surplus, or leave less than one month of bills in savings. Rejected options say exactly why.
Plain-English explanations: every recommendation comes with a short "why" and its trade-offs.
"What if?" simulator: a new baby, an income drop, or a longer commute, and the best move updates.
Human handoff: when no option is affordable, the top card is a TFS specialist, not a product.

How we built it

Frontend: React (Vite)
Backend: Flask API
Finance engine: deterministic Python that computes all of the math and ranking using standard loan amortization and lease buyout formulas, covered by 90 tests
AI explanations: The Gemini's model, Flash-lite 3.5, i writes the "why" only. A validator checks every number it writes against the engine's output; if any number doesn't match, the card falls back to a template.
Data: synthetic Toyota vehicles and contracts, plus banking data shaped like Capital One's Nessie API

Challenges we ran into

Keeping the AI honest: Gemini kept adding numbers it hadn't been given and repeating field names. We made the engine the only source of numbers and built a validator that checks every digit the AI writes; if one doesn't match, the card falls back to a template. We also hit the free-tier limit of 5 requests per minute and slow first responses, so we switched to a lighter model, added a 6-second timeout with template fallback, and cache explanations for the demo.
Working as a team of three in 24 hours: we ran it as a mini Scrum with 5 sprints, story points, and a stand-up at the end of each sprint. Every file has exactly one owner, which kept merge conflicts in code rare. Our shared backlog was the exception: two edits collided and we had to revert and redo one.
Git flow: one branch per GitHub issue, merged into dev. Fast-moving work meant branches went stale and some tasks were blocked waiting on others, so we published an API contract and sample JSON early so the frontend, engine and API could be built in parallel.
Communication: we had more ideas than time and debated a lot. Agreeing on the contract and the 3 demo customers early is what let us move fast after that.
Data vs. rules: when real numbers didn't produce believable recommendations, we adjusted the synthetic data, not the affordability rules, so the guardrails stay honest.