Getting a full-stack application running flawlessly on your local machine is a great feeling. Getting that same application to run flawlessly on the live internet is an entirely different beast.
This past week on MedReach AI, my teammate Collin and I tackled the deployment transition, moving our testing from the local emulator to a live production environment. We successfully deployed our FastAPI backend to Google Cloud Run and our React frontend to Firebase Hosting, but the journey wasn't without its hurdles.
Here is a look at the technical challenges we solved this week, and how we are preparing for our upcoming user testing phase.
The CORS Bouncer and the Cloud Run Fix
Right after our initial Firebase deployment, our frontend dashboard threw a wall of "Failed to fetch" errors under our executive metrics. The backend was alive, the frontend was live, but they were refusing to talk to each other.
The culprit was a classic CORS (Cross-Origin Resource Sharing) block. Our Google Cloud Run backend was acting like a strict bouncer, rejecting requests from our brand new Firebase URL because it wasn't on the approved list.
The Solution: We had to carefully strip out our local development overrides (like bypassing offline Firestore configurations) and update our main.py file to explicitly whitelist our Firebase Hosting origin in the FastAPI CORSMiddleware. By pushing these changes through our GitHub pipeline, Cloud Run automatically pulled the latest revision. Within minutes, the CORS block was lifted, and our live executive metrics populated perfectly.
Redesigning the Data Health Score UX
Once the data pipeline was connected, we realized we had a critical UX flaw on the Data Review screen.
Our system grades datasets across different categories, but the UI displayed the points as fractions (e.g., 20/20 or 21.3/25). At a glance, a perfect 25/25 score looked exactly like "25 unresolved errors out of 25," creating instant panic for the user. Furthermore, our PII/PHI (Personally Identifiable Information) scanner was acting purely as an advisory warning rather than deducting points from the overall data health score—a major oversight for a healthcare data platform.
The Solution: We overhauled the scoring logic and the UI. We rebalanced the 100-point total across five distinct 20-point categories, finally giving PII/PHI its own dedicated scoring bucket. If sensitive data leaks are detected, the dataset is actively penalized. On the frontend, we appended "pts" to the fractions (e.g., 20/20 pts) and grouped the record-level privacy detections under a dedicated tab. This small change completely removed the ambiguity between "points earned" and "flags detected."
Sprint Week 2: The "Think-Aloud" User Testing
With the production environment stable and the UI refined, this week is all about stepping back and letting fresh eyes tear it apart.
We are officially entering our user testing sprint. I have scheduled three Think-Aloud testing sessions with Melissa, Alex, and Aaron for October 7th through the 9th. Because they have not spent the last several weeks staring at this specific codebase, they are the perfect candidates to expose any assumptions we have made about the platform's intuitive flow.
During these sessions, I will be observing how they navigate the CSV upload process and whether the newly updated Data Review screen actually makes sense to a first-time user. Meanwhile, Collin is diving deep into end-to-end integration testing to ensure our backend handles payload mismatches without throwing 500-level errors.
Building software in a vacuum is dangerous. It’s time to see how MedReach AI holds up in the wild. I'll share the results of our testing sessions next week!
Top comments (0)