The Problem
Store-support work becomes difficult when every request has a different owner, urgency, category, and visibility rule. The person asking for help needs a simple path to submit and track work, while managers and technicians need enough control to triage, assign, update, and resolve it without breaking authorization boundaries.
HomeBase models that workflow as a full-stack request portal backed by service-layer role checks, category routing, and request history.
What I Built
I built the application around a request lifecycle that is readable to people and enforceable in code. Each request gets a human-readable REQ- number, a category, a team, a status, an assignee, comments, and history entries. The frontend exposes the right actions for each role, while the backend owns authentication, authorization, routing, persistence, and analytics.
Project Overview
HomeBase is an independent full-stack application with public source, demo screenshots, and repository documentation.
My Contribution
- Designed and implemented the request lifecycle, human-readable request IDs, status history, comments, category/team routing, technician queues, and analytics views.
- Built JWT authentication with access and refresh tokens, plus role-based authorization for Associate, Technician, Manager, and Admin users.
- Containerized the React and Spring Boot services and documented GitHub Actions, ECS Fargate, ECR, and RDS PostgreSQL deployment architecture.
Role Permissions
Role-permission model
The same request record is visible through different role-specific actions.
Roles and request categories are public source concepts; demo data is synthetic.
Request Lifecycle
Request lifecycle
A submitted request is routed by category, assigned, updated, resolved, and recorded in history.
The lifecycle is backed by request, team, comment, and status-history source evidence.
JWT Authentication
Access and refresh-token flow
Login produces scoped tokens; protected requests pass through backend authorization before workflow changes are accepted.
The token shape and refresh token type are visible in public frontend and backend source.
Evidence Screens
Dashboard overview
Real screenshot from the public repository's demo screenshots.
Demo account only. No private operational data is shown.
Request detail workflow
Real screenshot from the public repository showing the request detail surface.
The screen supports the request lifecycle, history, and comment claims in this page.
Deployment Architecture
Documented AWS deployment shape
The repository documents Dockerized frontend/backend services deployed through GitHub Actions to AWS infrastructure.
The old production URL did not resolve on August 3, 2026 and was removed from the linked README.
Technical Decisions
Keep workflow transitions behind the API boundary.
- A request can be viewed by different roles, but transition and assignment rules need one source of truth.
- The frontend has to handle explicit loading, validation, and forbidden-action states.
- Role-specific views stay simpler, and the backend remains responsible for durable workflow state.
How I Work
Engineering Challenge
- Role-aware interfaces can accidentally turn permission logic into scattered UI conditionals.
- I traced the request through creator, team, assignee, role, status, comment, and history data.
- I used role-specific UI affordances for clarity while preserving service-layer authorization and request ownership.
- The workflow is explainable from screenshots, but the important rules still live behind the API boundary.
Quality & Testing
Quality Evidence
Product engineering evidence
- The public repository includes a backend Spring test, frontend build/lint scripts, and a GitHub Actions workflow; local Maven/PostgreSQL execution was not available in this environment.
- GitHub Actions runs backend tests and frontend checks, then documents image build and AWS deployment steps on main.
- Source and docs verify Spring Security, JWT tokens, PostgreSQL/Flyway, React, Docker, ECS Fargate, ECR, and RDS PostgreSQL.
Public page quality
- Screenshots use descriptive alt text and diagrams use visible text labels.
- Architecture diagrams sit inside responsive case-study sections with scalable SVG geometry.
- Only public demo screenshots and source-backed claims are included.
| Area | Evidence | Published detail |
|---|---|---|
| Workflow | Public repository and application screenshots | Generic request lifecycle |
| Role behavior | Source code and README | Role-aware actions and status views |
| Deployment | Public README and infrastructure files | ECS Fargate and RDS architecture |
Results & Impact
HomeBase shows a complete enterprise workflow shape: authentication, four role levels, category routing, request ownership, activity history, analytics, screenshots, CI, containerization, and documented cloud deployment architecture. The live AWS URL is intentionally not linked because it did not resolve during Phase 10 verification.
What I Learned
The strongest workflow software is quiet about complexity. People see a request number and a status; the system underneath has to keep roles, teams, assignment, history, and persistence consistent.