The Problem
A mobile stock-tracking app needs to answer a basic question fast: what's happening with the stocks I care about, right now? That means live prices, a way to discover and search stocks, a watchlist that updates in real time, enough per-stock detail to be useful, and an account system to make any of that persistent per user — not just a set of screens with sample numbers in them.
What I Built
I built this in two phases. First, an HTML/CSS/JS wireframe prototype to work out the screen set and navigation. Then, a complete Flutter app that implements that same UX against a real backend: Firebase for accounts and per-user data, and Finnhub's public API for live market data.
Project Overview
This was proposed as a Mobile App Development group-project assignment — the course proposal template is literally titled 'Group Project Proposal.' Every commit across both build phases (18 total, confirmed via GitHub's commits and contributors APIs) is authored solely by me; no teammate is named in the proposal, wireframes, or app.
My Contribution
- Designed and built the wireframe prototype: login/signup, a tabbed stock-overview/trending-stocks home screen, a stock-detail page, portfolio, watchlist, newsfeed, and settings, in a shared Bootstrap phone-frame layout.
- Built the Flutter app end to end: Firebase Authentication (sign-up, sign-in, password reset, profile), a live-search tabbed home screen backed by Finnhub, a chart-driven stock-detail view, real-time watchlist price streaming, and a working newsfeed.
- Wired the state management, navigation, and shared chrome (app bar, drawer, bottom navigation, theme) connecting all of the above, and tracked functional progress across 16 commits over about three weeks.
System Architecture
Two-phase build: wireframe prototype to Flutter app
A browser-based wireframe explored the screen set and navigation first; the Flutter app then implemented the same shape against Firebase accounts and live Finnhub market data.
Diagram recreated from the wireframe files and the Flutter app's source tree. Excludes API keys, Firebase project values, and local paths.
The wireframe's stock-detail page prototyped a static P/E-ratio card; the real Flutter detail view ended up showing a live price chart and a company-profile panel (industry, market cap, IPO date, website) instead, driven by Finnhub's company-profile data rather than sample numbers. The Trending Stocks tab has its own detail view with a bar chart of analyst recommendation counts (strong buy/buy/hold/sell) — a feature the wireframe didn't have at all.
Technical Decisions
Design the full mobile UX in HTML/CSS/JS wireframes before writing any Flutter code.
- A browser-based wireframe was faster to iterate on for screen flow, navigation, and layout than rebuilding a mobile app for every UI change.
- Static sample data didn't have to match what a real market-data API could actually return, so some detail changed once real data replaced it.
- The Flutter app kept the wireframe's screen set and navigation shape, but its stock-detail view traded the wireframe's static P/E-ratio card for a real chart and company-profile panel once it was wired to live data.
Call Firebase and Finnhub directly from the Flutter client instead of building a custom backend.
- A solo build on a coursework timeline needed managed auth/storage and a ready market-data source rather than a hand-rolled server.
- Market data flows straight from Finnhub into the app with no server-side layer, and the trending-stocks feature has no dedicated 'trending' endpoint to call — it has to fetch the full exchange symbol list client-side and filter it, which the app's own README documents as a real, slow trade-off.
- Auth, search, live watchlist streaming, and news all work against real data within the coursework timeline, at the cost of that one slow screen and no backend to move the filtering into.
How I Work
Engineering Challenge
- The app's README documents a planned structure with dedicated provider classes and a standalone stock-details screen. By the time auth, search, watchlist streaming, and news were all wired to real data, some of those planned pieces were still empty files, and the Portfolio screen was still a placeholder with no entry point in the shipped navigation.
- I compared the README's documented file structure against what the code actually does — checking file sizes and which widgets each screen actually navigates to — rather than assuming the plan and the shipped app matched.
- The case study only describes what the shipped code does: real auth, live-search stock discovery, a chart-driven detail view, real-time watchlist streaming, and a working newsfeed. The unfinished Portfolio screen and the unused provider/model stub files are stated directly instead of implied to be complete.
- An accurate account of a solo, timeline-constrained Flutter build: most of the planned app shipped against live data, one screen didn't, and that's said plainly rather than smoothed over.
Quality & Testing
Quality Evidence
Product engineering evidence
- No automated test suite covers the real app — the repository's only test file is the unmodified default Flutter counter-widget smoke test. Verification was manual, tracked across commit messages progressing to 'All functionalities works as expected.'
- No CI is configured for the Flutter app. This portfolio page itself is verified through this site's lint, typecheck, unit, build, verify, e2e, responsive, and accessibility checks.
- Firebase Authentication and Firestore for accounts and per-user watchlist data, Finnhub-backed REST calls plus a live trade-update stream for market data, Provider for theme state, and fl_chart for the price and analyst-recommendation charts.
Public page quality
- The architecture diagram is a recreated SVG with descriptive title, description, and caption text, not a real screenshot.
- The case study uses the shared portfolio layout and was manually reviewed across mobile and desktop viewports, light and dark mode.
- No API keys, Firebase project values, GoogleService contents, or local paths are published in this case study.
Results & Impact
The result is a complete, solo-built mobile app: Firebase-authenticated accounts, a tabbed stock-overview/trending-stocks home screen with live search, a chart-driven stock-detail view, real-time watchlist price streaming, and a working newsfeed — implementing the same UX the wireframe prototype first explored, across 18 solo commits.
What I Learned
A written project plan and a shipped solo project rarely match exactly. This app's README documents provider classes and a detail screen that never ended up doing anything — the real functionality shipped through a simpler, more direct path instead, and the Portfolio screen didn't ship at all. Verifying what the code actually does, instead of trusting what a README or an old plan says it does, turned out to matter as much here as the Flutter and Firebase work itself.