About

Interdisciplinary builder
Profile photo of Nguyen Phuc Nguyen
Nguyen Phuc Nguyen
I approach problems like systems: data, people, incentives, and ensuring the output is usable.

Who I am

I am drawn to problems that look technical on the surface but fail in real life unless you connect engineering with context: infrastructure, adoption, policy, and human behavior.

Belief

AI as a component

I treat AI models as one layer in a larger system that must be measurable, usable, and trusted. If something fails, the root cause is often the surrounding workflow, not the architecture.

Method

Design from constraints

I start with reality: the data we actually have, how users behave, and the edge cases that break systems. Then I build the simplest design that stays reliable under those constraints.

North star

Trust > flashiness

I care about interpretability, reliability, and what happens after the demo: maintenance, failure modes, and whether the output genuinely helps someone decide.

The spark

A single question changed how I think about technology:
if AI is advancing so fast, why do critical problems still hurt people in predictable ways?

Flooding

When a “model” isn’t the missing piece

During severe flooding in Vietnam, I started from a naive assumption, “we just need a better predictor”, and discovered the harder truth: forecasting is not only computation.

Reality

Data and decisions come first

  • Data reality: advanced models mean little without reliable, real-time inputs.
  • Decision context: warnings only help if people can trust them and respond in time.
  • Domain complexity: terrain and drainage can dominate the outcome.
Direction

Build systems, not predictions

That spark pushed me toward work where the “last mile” matters: sensing, UX, reliability, and making outputs actionable for real stakeholders.

The main story

HFA – Health for All is where my mindset changed:
from optimize the model to stabilize the system

Chapter 01

The Beginning

I joined HFA as one of three builders, initially approaching it like many technical projects: define the problem, write the code, optimize the output. I took on the pieces I could execute directly—turning ideas into working prototypes, testing early pipelines, and iterating fast when the system didn't behave as expected.

Chapter 02

The Challenge

Once we moved beyond prototypes, the work became less clean and more honest. Medical data didn't fit neat assumptions. Edge cases appeared everywhere. Small errors created outsized consequences.

In our team check-ins, progress didn't always look impressive—sometimes it was hours spent tracing a single bug, validating signals, or rewriting a component because it wasn't dependable enough.

The “annoying” questions I kept asking
  • What happens when the device gives noisy readings?
  • What does the user do when the alert fires?
  • What information is actually useful to a doctor?
Chapter 03

The Shift

Our turning point came when we spoke with a doctor at the National Hospital of Endocrinology and learned about a patient in Thai Nguyen who couldn't travel regularly for monitoring. The doctor's message was direct: in healthcare, it's safer to consult experts than to rely entirely on AI.

As a three-person team, we made a hard decision: pivot from “AI diagnosis” as the headline to real-time alerts that help connect patients and doctors. That choice forced us to prioritize responsibility over flashiness—and to build for trust, not just performance.

Chapter 04

What I Learned

After the pivot, I stopped thinking of AI as the product and started thinking of it as one component in a larger system: user behavior, device reliability, clinical workflow, and communication under pressure.

My work became less about chasing perfect metrics and more about making the system stable, interpretable, and usable in real life—because a health tool that isn't dependable is worse than no tool at all.

Usability
Design for what users do under stress, not what they do in a demo.
Reliability
Handle noise, edge cases, and failures as first-class requirements.
Clinical workflow
Support experts instead of replacing them; integrate with real decision paths.
Next

See how I build

If you want the technical side — prototyping, engineering, and system design — the Engineering page shows the work.

Go to Engineering