Case Study · Full-Stack · Accessibility
A calm, accessibility-first full-stack productivity application designed to support routines, focus, and progress without pressure.
Overview
Bloom began as a frontend prototype exploring calmer productivity for neurodivergent users. It has since evolved into a full-stack application with authenticated accounts, persistent routines, protected routes, guided demos, and accessibility-first design.
Rather than rewarding long streaks or encouraging pressure, Bloom focuses on helping users return after missed days with supportive routines and gentle progress tracking.
Problem
Many productivity applications rely on streaks, constant notifications, dense dashboards, and visible signs of missed progress. For neurodivergent users, this can turn planning into another source of pressure.
Bloom was designed around a different question: how can a productivity tool help someone return to a routine without making them feel that they have failed?
Solution
Bloom combines routines, focus sessions, progress tracking, reflections, guided demos, and accessibility controls within a calm interface.
Visitors can explore the application without creating an account, while authenticated users can save their routines, profile preferences, and progress through a FastAPI and PostgreSQL backend.
Features
Secure registration, login, JWT authentication and protected routes.
Create routines, complete steps and track progress across sessions.
Visitors can explore Bloom instantly without creating an account.
Designed with calm visuals, accessibility settings and neurodivergent-friendly UX.
Architecture
Bloom uses a separate frontend, backend, and database architecture. The React client communicates with a FastAPI API, while PostgreSQL stores authenticated user data, routines, preferences, and progress.
Engineering Decisions
Challenge
Bloom needed a guided demo that visitors could explore without creating an account, while ensuring demo activity never affected authenticated user data.
Decision
I treated demo mode as a separate application path with sample data and isolated state rather than storing demo actions in PostgreSQL.
Outcome
Visitors can explore and experience Bloom immediately, while registered users retain private and persistent account data.
Challenge
The project began as a frontend prototype, so introducing authentication and persistence risked making the application feel more complex.
Decision
I kept the existing React frontend and added a FastAPI and PostgreSQL backend behind clear login, protected-route and persistence boundaries.
Outcome
Bloom evolved into a real full-stack application without removing the guided-demo experience.
Challenge
Traditional streak-based productivity systems can make missed days feel like failure.
Decision
I designed the product around routines, gentle completion feedback and returning without penalties rather than preserving a perfect streak.
Outcome
The interface better reflects Bloom's accessibility-first goal and gives the project a clearer product identity.
Learning
Bloom has been my main capstone project. It combines frontend, backend, database, accessibility and engineering workflow skills.
How to evolve a frontend prototype into a full-stack application without rebuilding the entire user experience.
How to connect React to a FastAPI backend and persist authenticated user data in PostgreSQL.
How to separate public demo behaviour from private account data.
How to use protected routes and JWT authentication across the frontend and backend.
How accessibility decisions affect navigation, content density, feedback and product identity.
How to manage releases through GitHub, feature branches, Jira issues and structured documentation.
Project Timeline
Bloom has developed through several focused releases, moving from a frontend prototype into a deployed full-stack application.
v1.0.0
Created the first version of the routine and task experience.
v1.1.0
Added task completion behaviour and clearer progress feedback.
v1.2.0
Introduced daily routine reset behaviour and improved return flows.
v1.3.2
Refined spacing, layout consistency and responsive behaviour.
v1.4.0
Added clearer empty states and guidance for users with no saved content.
v1.5.0
Improved presentation, project documentation and public-facing polish.
v1.6.0
Completed a major frontend polish pass and expanded accessibility controls.
v2.1.0
Added FastAPI, PostgreSQL, authenticated accounts, protected routes and persistent user data.
v2.1.1
Verified account persistence, user isolation, protected routes and demo separation.
Next Steps
Bloom remains in active development. The next phase focuses on mobile usability, clearer product guidance, broader accessibility support and stronger production readiness.
Reduce visual density, simplify key controls and improve bottom-sheet interactions across smaller screens.
Make the relationship between routines, focus, progress and returning after missed days easier to understand at a glance.
Add high-contrast support, reduced-motion preferences, stronger keyboard navigation and further screen-reader improvements.
Expand automated frontend and backend tests, add stronger error tracking and improve deployment observability.