Inspiration
Most financial quizzes give you a number and leave you there. You get 62 out of 100, or a label such as "average," but what are you supposed to do with that? It does not tell you which ideas you understand, which decisions caused problems, or what you should learn next.
We kept coming back to that problem while building AlterScore. We did not want to make another quiz that marks answers right or wrong and then produces a mysterious score. We wanted users to see where their financial knowledge stands and understand why.
We also wanted to avoid judging people through their salary, identity, credit history, or personal documents. AlterScore looks at how someone thinks through practical money situations. That felt like a fairer and more useful place to start.
What AlterScore does
AlterScore is an educational financial-readiness assessment for students, first-time earners, and anyone trying to become more confident with money.
The questions deal with situations people can recognise: paying bills, protecting savings, handling an unexpected expense, deciding whether to borrow, and managing money when income is uncertain. Some of those questions are connected. If you spend more money now, you have less available in the next situation. If you protect your emergency reserve, you may need to accept a different cost somewhere else. Earlier decisions change what happens later.
Once the assessment is complete, AlterScore shows a Financial Decision Index from 0 to 100. The number is only one part of the result. Users can also see where they did well, where their understanding appears weaker, how their choices affected the outcome, and what they could work on next. AlterScore is meant for learning. It does not decide whether someone deserves a loan, predict whether they will repay one, or replace professional financial advice.
How we built it
We built the frontend with React, Vite, and CSS. The backend runs on FastAPI with Python and Pydantic.
The assessment uses a mix of short calculations, judgement questions, and connected scenarios. We chose that mix because knowing a formula is different from making a decision when several priorities compete for the same money.
During a scenario, AlterScore keeps track of values such as available cash, unpaid obligations, emergency savings, and added costs. Each answer updates that financial state. The next question then begins with the situation the user created. The quick trial looks at four parts of the final position:
$$ S = 0.40O + 0.25L + 0.20C + 0.15P $$
In this formula:
- (O) measures how much of the required obligation was covered.
- (L) measures how much usable liquidity remained.
- (C) measures how well the user avoided unnecessary costs.
- (P) measures whether the remaining plan is still workable.
There are no isolated 20-point questions hidden behind the interface. The score comes from the final financial position created by the user's full path.
The full assessment is scored on the server. It uses one-time attempts so the same assessment cannot be submitted twice by accident. AlterScore also returns a signed, redacted summary that can be verified without exposing the user's identity or raw answers.
How we used Codex and GPT-5.6
We used Codex with GPT-5.6 while planning, coding, testing, and polishing AlterScore. A lot of its work began with reading code that already existed. Codex traced how assessment data moved between the frontend and backend, found places where those contracts did not quite match, and helped us fix them without replacing working parts of the project.
It also helped us build the quick trial, debug state and navigation problems, improve the experience on smaller screens, and test keyboard and reduced-motion behaviour. When a result page occasionally appeared blank after a route change, Codex helped trace the problem across storage, navigation, and rendering instead of treating it as an isolated UI bug.
We also used it to write focused tests and check the final release. That saved us time, especially when a change touched several parts of the assessment.
Codex does not score users while AlterScore is running. We used it to build and verify the product. The scoring itself stays deterministic because users should be able to understand where their result came from.
Challenges we faced
The hardest question was where to draw the line. We were building something related to financial readiness, but we did not want it to become a softer-looking version of a credit score. That affected almost every decision we made. Identity stays outside the scoring process. Reflection questions do not affect the result. The interface repeatedly explains that AlterScore is for education, not lending or approval.
The connected scenarios caused plenty of headaches too. If a user went back and changed an earlier decision, the answers that followed might no longer make sense. We had to clear those answers, rebuild the later state, and make sure the final explanation matched the new path exactly.
The result page was another difficult part. There was a lot we wanted to show: the score, calculations, financial state, trade-offs, recommendations, and a replay of each decision. Putting everything on screen at once felt like handing the user a spreadsheet. We ended up showing the main result first and placing the detailed evidence behind sections users can open when they want to dig deeper. Then there were the less glamorous problems that still mattered: narrow phone screens, keyboard focus, reduced-motion settings, expired attempts, accidental double submissions, and route changes that did not always behave as expected. Solving those issues took a surprising amount of the build time.
Accomplishments that we're proud of
Seeing the full assessment work from beginning to end was a big moment for us. A user can make a decision, watch it change the next financial situation, finish the assessment, and then trace the result back through every choice they made. The score does not appear from a black box. Users can see where their financial knowledge stands and why.
We are especially happy that we achieved this without asking for a login, credit history, or personal financial documents. The full assessment still has secure one-time attempts and a signed result that can be independently verified. Getting explainability, privacy, and a smooth user experience to work together took a lot of effort, and it is the part of AlterScore we are proudest of.
What we learned
We learned that an explainable score has to be designed backwards from the explanation. If the scoring system does not keep track of evidence and state changes, the interface cannot honestly explain the result later. A paragraph generated after the fact is not enough. The questions, scoring rules, API responses, and result page all need to agree. We also learned that consequences teach better than answer keys. A choice can solve today's payment problem while using up the emergency reserve needed tomorrow. Another option may protect cash but add borrowing costs. Seeing that happen makes the lesson easier to understand than simply being told that an answer was wrong.
Our experience with Codex changed during the project as well. At first, it was tempting to think of it mainly as a faster way to write code. It became more useful when we asked it to trace complete user journeys, question our assumptions, test awkward edge cases, and inspect how a small change affected the rest of the system.
What comes next
We want to add more scenarios around budgeting, saving, borrowing, irregular income, and emergency planning. Different regions also use different currencies and talk about money differently, so localised examples are high on our list.
We are interested in letting users see how their understanding changes over time, but only if we can do it without weakening the privacy choices already built into AlterScore.
The next step is to put the product in front of students and first-time earners. We have tested whether the system works. Now we need to learn whether the explanations make sense to the people it was built for.
Built With
- css
- docker
- fastapi
- github-actions
- gpt-5.6
- hmac-sha256
- hugging-face-spaces
- javascript
- openai-codex
- pydantic
- pytest
- python
- react
- rest-api
- vercel
- vite
- web-crypto-api
Log in or sign up for Devpost to join the conversation.