Display financial accounts and their current balances.
Loading page content
A full-stack budgeting application built to turn financial data into clear, usable insights.
Financial Website Prototype is a full-stack web application developed to explore how personal financial information can be organized, stored, and presented through a practical user interface. Built with Blazor and SQL Server, the project allowed me to work with account data, budgeting workflows, database-backed applications, and dashboard design while strengthening my understanding of full-stack software development.
[PROJECT SCREENSHOT]Financial website dashboard displaying account balances, budgeting information, and financial summaries.
Financial information is often scattered across accounts, statements, spreadsheets, and disconnected tools. I wanted to explore how a single application could organize this information into a clearer system where users could view accounts, monitor balances, and better understand their overall financial position.
[PROJECT SCREENSHOT]Financial dashboard showing account summaries, balances, and budgeting information.
Display financial accounts and their current balances.
Allow users to create, view, update, and manage financial records.
Organize financial information into clear dashboard summaries.
Store application data in a relational SQL Server database.
Present budgeting and account information through reusable interface components.
Provide a complete workflow between the user interface, application logic, and database.
Maintain a clear and approachable financial interface.
Separate presentation, business logic, and data-access responsibilities.
Use a relational data structure that supports future expansion.
Provide consistent validation and error handling.
Create reusable and maintainable application components.
Keep the prototype responsive and usable across common screen sizes.
The prototype follows a layered full-stack architecture built around a Blazor user interface, C# application logic, and a SQL Server relational database. Each layer handles a specific responsibility, allowing financial data to move from persistent storage through application services and into reusable dashboard components.
[ARCHITECTURE DIAGRAM]High-level architecture of the financial website prototype.
Displays account information, financial summaries, forms, and dashboard components through the Blazor interface.
Coordinates user actions, financial workflows, data validation, and communication between the interface and database.
Handles database queries and the movement of structured financial information between SQL Server and the application.
Stores account records, balances, budgeting information, and related financial data using relational tables.
Designed a SQL Server data model to store financial accounts and related information in a structured format. This introduced practical considerations such as table relationships, identifiers, data types, and maintaining consistent records.
Technical callout
The relational structure was designed to support future financial features without placing all application data into a single table.
Implemented workflows for displaying and managing financial account information, allowing users to interact with stored records through the web interface.
[PROJECT SCREENSHOT]Account management interface showing financial accounts and balances.
Technical callout
Connected user-facing forms to database-backed account operations.
Created dashboard components that summarize account information and present financial data in a format that is easier to understand than raw database records.
[PROJECT SCREENSHOT]Financial dashboard displaying account summaries and balance information.
Connected the Blazor application to SQL Server so financial information could be retrieved, displayed, updated, and persisted between sessions.
Technical callout
This project strengthened my understanding of how front-end interfaces communicate with persistent relational data.
Added validation to financial input workflows to reduce invalid records and provide clearer feedback when users entered incomplete or incorrect information.
Designed the interface around clarity and readability, using reusable components to keep account information, actions, and financial summaries visually consistent.
Database decisions affected nearly every part of the project. Clear tables and relationships made application logic easier to understand, while poorly structured data would have created unnecessary complexity throughout the system.
Even a simple account-management feature required coordination between the interface, validation logic, application code, database queries, and stored records.
Users need to understand balances and account information quickly. Clear labels, logical grouping, and restrained layouts were more valuable than adding unnecessary visual complexity.
Building a working prototype exposed design, data, and usability considerations that would have been difficult to identify through planning alone.