Inspiration
Most personal finance tools focus only on bank balances and budgets, while career tools focus only on resumes and jobs. We wanted to explore a broader picture of personal wealth: what someone owns, what they can earn, and how those pieces connect. MoneyMirror was inspired by the idea that a person’s financial future includes both tangible assets and human capital.
What it does
MoneyMirror gives users a unified view of their financial and earning potential.
Users can:
- Track financial assets and liabilities and calculate net worth.
- Upload photos of possessions for AI-assisted object detection, identification, valuation, and inventory management.
- Review, correct, save, merge, and revalue physical assets.
- Upload a resume and extract a structured professional profile.
- Review and correct extracted education, experience, certifications, skills, and projects.
- Explore occupation matches, compensation estimates, skill gaps, and future opportunities.
- See financial net worth, physical capital, and Market Potential together while keeping them clearly separate.
How we built it
MoneyMirror is built as a .NET 9 Blazor Web App with a modular feature-based architecture.
The application uses:
- ASP.NET Core and Blazor Server for the interactive web experience.
- PostgreSQL and Entity Framework Core for persistence.
- NVIDIA Nemotron for language-based extraction and explanations.
- NVIDIA’s vision model for possession detection and identification.
- The BLS Public Data API for wage observations.
- Deterministic C# calculations for net worth, compensation aggregation, skill gaps, and opportunity ranking.
- Local filesystem storage for uploaded possession images.
- Automated unit and integration tests covering the core services and data flows.
AI is used where it adds value, but important numbers are designed to be calculated deterministically and accompanied by their supporting evidence.
Challenges we ran into
The biggest challenge was building several AI-assisted workflows without letting the AI become an unreliable source of truth. We had to distinguish between identifying an object, estimating a value, calculating a value from evidence, and explaining that value.
We also had to coordinate a large dependency graph across financial data, physical assets, resume extraction, occupation matching, compensation, and dashboard integration. Keeping the application usable while those capabilities were being built in parallel required careful interfaces, incremental persistence, and frequent integration work.
Another challenge was mapping real-world occupation data to reliable wage data. The BLS API provides valuable wage observations, but turning those observations into meaningful occupation matches requires explicit series mappings and evidence tracking.
Accomplishments that we're proud of
We are proud that MoneyMirror became more than a collection of disconnected prototypes. The major workflows now connect:
- A possession can move from image upload to detection, review, valuation, inventory, and net-worth impact.
- A resume can move from upload to structured profile, correction, occupation analysis, compensation, skill gaps, and opportunity modeling.
- Users can see financial capital, physical capital, and Market Potential in one dashboard without collapsing them into a misleading single number.
- The application preserves valuation history, detects possible duplicate assets, supports corrections, and handles failure states instead of silently fabricating results.
- The project has a substantial automated test suite covering API parsing, deterministic calculations, persistence, validation, and AI-service failure cases.
What we learned
We learned that AI features need strong boundaries. The most trustworthy design is often:
- external data for evidence,
- deterministic code for calculations,
- and an LLM for interpretation and explanation.
We also learned that product integration is its own engineering problem. A feature can work in isolation and still fail to feel complete if the user has to manually navigate between every step. Clear progress states, persistence, error handling, and end-to-end flow matter as much as the individual model calls.
Finally, we learned to treat uncertainty explicitly. A guessed value, an evidence-backed value, and an unavailable value should never look identical to the user.
Log in or sign up for Devpost to join the conversation.