MyFinance Frontend Designed: From System Schemas to User-Ready Screens

Frontend Design Wrapped 🎉 — MyFinance Dev Update

I can hardly believe it’s only been 12 days since I started building MyFinance. (To be honest, it felt even longer for how much I processed in those days. The result? I really like where it landed MyFinance holds way more information and complexity compared to MealMatch, and I’ll get into why!)

Starting with System Design

Before touching Figma, I mapped out backend schemas, data tables, data flows… basically all the structure from the ground up. As I moved into frontend design, some of those choices needed realignment—which just proves how closely backend and frontend play together. That’s what makes me proud to call myself a full stack developer now; I enjoy shaping both and seeing how each informs the other. Watching the logic (“bones”) and the interface (“skin”) come together, evolving in sync, is deeply satisfying—especially when it all just starts to make sense for this app’s unique needs.

The Evolution (What I Had vs. What I Changed)

Page by page, my design instincts grew. I kept asking myself: what do I really need to see (not just what would be “cool”)? I focused on showing crisp separations between information blocks—this is a data-driven app, after all, with not much imagery or fluff. Each block needed clear segmenting, so data is readable (and, dare I say, a little inviting?). By the final screen, I noticed I’d developed a consistent style for lists, inputs, and modals—so I looped back and updated the earlier pages for a unified MVP look.

The Finished Design (So Far)

Here’s the current lineup of 5 main pages (and what changed):

Login/Register
Totally refreshed with new input styles and containers. These now fit the background narrative and feel much more futuristic—so good, they’re almost “fun” to fill out!
Dashboard
Updated data blocks with my current design language. I plopped in new "side" blocks that display investments and miscellaneous spending for the current month—turns out, these were just what the page needed. Recent incomings and outgoings show up in up-to-date tables.
Incomes/Outcomes
These pages are basically the birthplace of the new style. At first, the content was there, but it looked bland. With a new component system and better background, both pages are way cleaner and actually nice to look at, no matter how much data you throw at them.
Investment
Here’s where things got really interesting. There’s a LOT more relevant data to surface than I first thought—assets, profit/loss, types, and more. I intentionally kept the scope tight so I wouldn’t overbuild, but re-used small components for new types of info. It’s also where I realized the importance of relational data: investments link to assets, returns, and user activity in ways a pure document database can’t easily handle. I started out building with MongoDB, but the deeper I went, the clearer it became—this project’s structure begs for a relational database. I’m now researching my options:
- PostgreSQL: Handles relationships, powerful queries, open source, huge community.
- MySQL: Mature, widespread, great performance, but not as flexible for JSON or modern types.
- Supabase: Postgres-based with instant APIs/auth, but still a bit new for mission-critical stuff.
I haven’t picked one yet, but diving into relational DBs makes this project even more valuable for me—I’m learning Next.js and TypeScript, then adding serious SQL design to my stack!
Profile
The simplest page, showing only what I need from the user: username, email (for auth/comms), the reset date for their monthly statement, and base currency for future features.

Modals for Editing Data:
There’s one main modal for editing, but it’s super reusable—swapping content as needed from page to page, styled for clarity and easy option selection or confirmation.
A Bunch of Small, Reusable Components:
Core to keeping things DRY and maintainable.
Custom Buttons and Input Fields:
Unified style, with color feedback and clear affordances everywhere.

In all honesty, designing for the large screen is now DONE—the structure is locked in, and every part fits just right. All that’s left is implementation, testing, and deployment. It feels wild to write that!

What’s Next?

Much as I’d love to skip it, there’s no shipping a web app in 2025 that isn’t responsive. So mobile-first and tablet designs are next on my list. Once that's in place, I can finally dive deep into the codebase, start plugging in data, and let the real logic shine. I’m actually looking forward to untangling backend aggregates and complex queries with my new relational DB setup!