AfterCare

About the Project

AfterCare was built around a gap that exists in almost every surgical workflow: once a patient leaves the hospital, recovery becomes largely invisible. Patients are expected to manage pain, medications, wound care, and symptoms at home, while care teams have limited visibility into how recovery is actually progressing day to day.

We designed AfterCare as a post-operative recovery monitoring platform that extends care beyond discharge. The goal was to create a system where patients can consistently log their recovery signals—pain, symptoms, wound status, mobility, and medications—while clinicians can monitor those signals in a structured, actionable way. Instead of relying on sporadic follow-ups or patient-initiated calls, the platform enables a more continuous, proactive view of recovery.

The product is intentionally framed as a realistic, interactive prototype. It uses seeded data and deterministic logic, but is designed to feel like a production-grade healthcare tool that patients, surgeons, and care teams could actually use.

How We Built It

We built AfterCare as a full-stack web application using Next.js, React, TypeScript, Tailwind CSS, Recharts, and Supabase/Postgres, with a strong focus on clean architecture and role-based system design.

The platform is structured around three core experiences:

• Patient application – a mobile-first interface where patients log daily recovery data through guided check-ins, track trends over time, upload wound images, manage medications, and communicate with their care team
  
• Surgeon portal – a high-signal dashboard that surfaces patient risk, recovery trends, wound status, and alerts, allowing clinicians to quickly prioritize attention
  
• Admin / practice layer – a lightweight operational view for onboarding, audit logs, and system-level configuration
  

As the project evolved, we moved from frontend-heavy mock data to a structured Supabase-backed data model, which forced us to think more rigorously about:

• relational schemas for patients, procedures, and logs
  
• API boundaries and data access patterns
  
• normalization and consistency across entities
  
• how frontend interactions map to persistent state
  

This shift was critical in making the product feel less like a UI demo and more like a cohesive system.

What We Learned

The biggest takeaway was that healthcare software is fundamentally about trust and clarity, not just functionality.

A polished interface alone isn’t enough—information needs to be:

• clearly prioritized
  
• clinically interpretable
  
• presented in a way that supports decision-making without overwhelming the user
  

We also learned how important role-based design is in healthcare systems. Patients, surgeons, and administrators interact with the same underlying data, but their workflows, context, and required level of detail are completely different. Designing those experiences in parallel forced us to think carefully about what each user actually needs to see—and what they shouldn’t.

From an engineering perspective, the project reinforced the importance of data modeling as a foundation for product design. Once we introduced a real backend layer, decisions around schema design, data consistency, and relationships became just as important as the UI. It highlighted how quickly a system can break down if the underlying data model isn’t well-structured.

Challenges We Faced

One of the main challenges was reconciling inconsistencies in our initial mock data. Different parts of the project used mismatched patient identifiers, naming conventions, and provider relationships, which made it difficult to transition to a reliable backend. We had to normalize these relationships and establish a consistent data model before the system could function cohesively.

Another challenge was balancing realism with responsibility. We wanted the platform to feel clinically meaningful—especially in areas like wound analysis, pain trends, and alerting—while still making it clear that this is a prototype with simulated logic, not a real diagnostic system. Maintaining that balance required careful attention to both the product language and the system behavior.

Overall, the project pushed us to move beyond building a polished interface and instead focus on creating something that feels structured, credible, and extensible as a real product.

Built With

• next.js
• supabase
• typescript