F1 - Finance1

The problem you are solving and who it affects

More than a million international students enroll at US universities each year, and almost all of them hit the same wall in their first weeks: US financial setup — a bank account, a Social Security Number, enrollment fees, an international-student-office check-in — is not a checklist, it's a dependency graph, and nobody hands you the graph.

The real process is conditional: you can't request an SSN eligibility letter without a job offer and a completed check-in and that letter itself gates applying for the SSN. Whether you're blocked right now depends entirely on facts about your specific situation — something generic "how to get an SSN as an international student" advice can't capture, because it isn't written for your situation, it's written for everyone's. Students end up doing things in the wrong order, missing fixed-date deadlines, or emailing offices that already have a self-service portal for exactly what they're asking about.

How your solution works

FinanceOne takes a student's situation — university, visa type, job-offer status, what they've already completed — and resolves it against a fixed 7-step dependency graph: confirm US address, complete international-student-office check-in, open a bank account, pay the enrollment fee, request the SSN eligibility letter, apply for the SSN, get a student ID. Each step comes back as done, ready, or blocked, with the exact blocking reason, computed by a deterministic resolver with no AI involved in that decision.

On top of that resolved plan, an LLM writes a plain-language explanation of each step, grounded in real university documents retrieved for that specific school and visa type — and it never gets to override or re-decide status, only explain and draft within what the resolver already determined. The same boundary applies to artifact generation: drafting a request email is gated on the resolver's state, so the model can't draft "I have a job offer" for a student who doesn't.

Every step links to the real place to take the action — an actual self-service portal, an office locator, a payment portal — rather than a generic "contact us." Marking a step done immediately triggers a separate deterministic recommendation engine that decides what to surface next. The whole thing is a single-account dashboard — Home, Tracker, Docs, FAQs — not a chat interface; there is no open-ended chat box anywhere in the product.

Which models, APIs, and frameworks you used and what they actually do

• Groq API (Llama 3.3 70B) — generates the per-step plain-language explanations and drafts the ISSS request email. Constrained by prompt design to the resolver's already-decided status and reasons, and gated so it's only ever called once those reasons make sense to act on.
• Chroma (vector database) — stores and retrieves the university-specific and general onboarding documents that ground the LLM's explanations, filtered by university and visa type via metadata.
• FastAPI — serves the resolver, RAG retrieval, recommendation engine, document store, and artifact-generation endpoints as a REST API.
• Next.js, Tailwind CSS, shadcn/ui — render the dashboard: the account switcher, the tracker's step cards, the progress ring, the document grid.

What you built during the hackathon versus what existed before

The repository was empty at the start. Everything was built during the hackathon: the deterministic resolver and its dependency graph, the recommendation engine, the RAG pipeline and its document corpus, the LangGraph intake orchestration, the document store with upload and seeded sample documents, the complete frontend across all four pages, the visual design and branding, and the deployment configuration for both the frontend and backend hosts.

Your complete tech stack

Backend: Python, FastAPI, Pydantic, Chroma, Groq API via an OpenAI-compatible client, icalendar, python-multipart, uvicorn.

Frontend: Next.js (App Router), React, TypeScript, Tailwind CSS, shadcn/ui, lucide-react.

Deployment: Vercel (frontend), Render (backend).

Source control: GitHub.

Challenges you ran into

The first time the LLM connection went live, it immediately surfaced two real bugs: a stale internal lookup table that crashed on two step types, and an AI-drafted email that confidently stated a student had a job offer and had completed check-in when neither was true. The fix for the second one wasn't a better prompt — it was gating the draft generation on the same deterministic state that decides everything else, so the model is never asked to write something that isn't true yet.

Installing a UI component library mid-build silently overwrote custom theme configuration — the background color, a font reference, and a dark-mode code path that had been deliberately removed came back without warning, and had to be found and fixed by hand.

A script written to automate a color-scheme change corrupted the indentation of nine source files in a single pass; caught before it shipped and rewritten clean.

Deploying the backend onto a stateless serverless platform would have silently broken the core interactive feature — marking a step done and watching the plan update — since that depends on a persistent process, not a fresh instance per request. Splitting the deployment (frontend on one platform, backend on another that keeps a persistent process) resolved it. Getting the frontend deployment itself configured correctly required working through an auto-detected multi-service project mode and matching its configuration schema exactly against the platform's own documentation.

What is next for the project

Wire uploaded and seeded documents into the resolver itself, so an uploaded I-20 or admission letter can satisfy a step's precondition directly rather than sitting alongside the plan as reference material.

Extend the university corpus beyond the first school and parameterize the fee deadlines and action links per institution instead of a single hardcoded set.

Bring the conversational intake flow into the main product surface as the way a new student creates their own account and situation.

Move state into a persistent database.

Add multilingual support built around a deliberately chosen set of languages.

Built With

• chroma
• fastapi
• next.js
• pydantic
• python
• react
• render
• typescript
• vercel