BehaveHealth

What the engagement looked like.

BehaveHealth was building software for behavioral health facilities — the kind of product where the UI reads staff notes, schedules interventions, and tracks patient states across a shift. The domain mattered as much as the craft. I joined a small team that needed someone comfortable switching between design decisions, frontend patterns, and the clinical logic behind a screen.

The problem on arrival.

Healthcare software sits in a narrow band: too sparse and clinicians lose trust, too dense and the interface gets in the way of care. The team needed UI decisions made by someone willing to sit with the problem before opening a code editor.

The engineering side had React and Node experience but wasn’t set up to carry design judgment by itself. Handoffs from a separate design track would have slowed the product at exactly the moment it needed to move.

How it came together.

3 phases, each one trying to prove a single thing before the next could start.

1. Early on
   Domain before interface

   Studied the workflows the product was meant to support — shift notes, intervention logging, state transitions. Mapped the product shape around those, not around a generic CRUD model.

2. Middle
   Connected surfaces

   Built the patient record, the intake flow, and the intervention timeline as three surfaces that read each other’s state. Design and code moved together, no handoff layer.

3. Late
   Productization

   Tightened the product against actual facility usage. Each iteration came from observation, not opinion.

What shipped.

Shipped the core product into live facility use. Clinical staff can track state, log interventions, and produce the documentation the facility needs — without the software getting in the way. The pattern of one person carrying design and engineering together kept the product coherent through an entire year of iteration.