Matthew Huang

Case study

Hypercare

At Hypercare, I worked on a healthcare communication SaaS product used by medical organizations. One of the most important projects I contributed to was Single Sign-On (SSO), where the challenge was not only technical implementation, but also reducing complexity across iOS, Android, web, and legacy enterprise environments.

SwiftUIKitGraphQLSSOWebView-based authentication

Why this project matters

This project shows how I handled a steep domain ramp-up, worked through enterprise authentication complexity, and proposed a simpler cross-platform solution that reduced client-side implementation risk for both iOS and Android.

Challenge

When I first joined Hypercare, I was under pressure to get familiar quickly with both the technical stack and the product domain. The app used technologies I had not worked with deeply before, including GraphQL, and it also served medical organizations, which meant I had to learn healthcare-related workflows and terminology in a short period of time. After about two months, the team needed to deliver a major feature: Single Sign-On (SSO). The problem was highly complex. Older or custom-built enterprise systems often did not support modern authentication protocols cleanly, which created compatibility issues. There were also device-specific challenges, especially across iOS, Android, and other platforms with different authentication assumptions. On top of that, the sign-in and sign-up flows involved too many screens, too many states, and too many edge cases to implement separately in each mobile client without creating major complexity and maintenance risk.

Hardest problem

The hardest problem was finding a solution that could support the complexity of enterprise authentication without forcing both iOS and Android to duplicate a large, fragile set of authentication flows. If each client implemented the full SSO logic natively, the result would have been a high-maintenance system with many screens, edge cases, and platform-specific bugs. I needed to find an approach that was practical, scalable, and realistic for the team to ship.

What I owned

  • Ramped up quickly on the Hypercare tech stack, including GraphQL, and learned the product domain for healthcare organizations in a short period of time.
  • Helped evaluate how SSO should be implemented across mobile clients in a way that reduced complexity and delivery risk.
  • Proposed that iOS and Android use a webview-based authentication flow instead of duplicating the full sign-in and sign-up logic natively on both platforms.
  • Contributed to validating the approach through demos and technical discussion so the team could align on a practical implementation path.

Architecture and approach

  • Looked at the problem from a systems perspective instead of only from the iOS client perspective.
  • Recognized that the most complex part of SSO was the authentication flow itself, not the final token handling on mobile.
  • Proposed centralizing the authentication logic in the web experience, then letting iOS and Android clients use a webview to handle the sign-in flow and receive the returned tokens and keys afterward.
  • Used demos and validation work to show that this approach could significantly reduce complexity on both mobile platforms while keeping the user flow workable.
  • Focused the mobile implementation on handling the returned authentication state cleanly, instead of rebuilding the full SSO flow natively.

Collaboration

  • Worked with teammates across platforms while I was still ramping up in a technically and domain-heavy product environment.
  • Helped align both iOS and Android around a shared implementation model instead of having each client solve the same authentication complexity separately.
  • Used a demo-driven approach to show why the webview-based solution was more practical and easier to maintain.
  • Contributed to a cross-functional decision that simplified delivery and reduced duplicated effort between teams.

Tradeoffs and obstacles

  • Chose a webview-based authentication flow over full native implementation because it reduced duplicated complexity across iOS and Android.
  • Accepted that a pure native experience was less important than having a reliable, maintainable, and realistic enterprise authentication flow.
  • Optimized for implementation simplicity and long-term maintainability in a feature with many edge cases and external dependencies.
  • Focused the mobile clients on the parts they actually needed to own, rather than letting them absorb all of the SSO complexity.

Outcome and impact

  • Helped the team converge on a simpler SSO implementation strategy for mobile clients.
  • Reduced the amount of duplicated authentication logic that iOS and Android would otherwise have needed to build and maintain.
  • Made the feature more realistic to deliver by centralizing the most complex logic in the web layer.
  • Supported a smoother implementation process after the team aligned on the simplified architecture.

What I learned

  • When joining a new domain-heavy product, fast learning and structured simplification become just as important as pure implementation speed.
  • In complex enterprise features, the best solution is often the one that reduces duplicated responsibility across platforms.
  • It is often better to centralize the most complicated business logic in one place rather than rebuild it separately in every client.
  • A good technical proposal becomes much stronger when it is supported by a concrete demo instead of only abstract discussion.

What I would improve next

  • I would document the client-web authentication contract even earlier so platform teams can align faster.
  • I would add more structured notes around SSO edge cases and failure handling to make future maintenance easier.
  • I would continue looking for opportunities to reduce duplicated complexity between clients and shared platform layers.