Paying down the innovation tax: how migraine shipped in months not years
When Hinge Health launched its Migraine Care Program, a small and nimble team delivered the product work in months. That speed was real, but it's only part of the story. Migraine was our first expansion into a MSK-adjacent area, and it was possible because of foundational platform work that began well before the implementation sprint.
This was not a case of rushing a product out the door. The engineering build sat on top of years of work across the company: clinical research, hardware prototyping, member research and commercial planning. It also reflects a year of platform investment involving dozens of engineers.
The problem we had to fix first
For years, every new program at Hinge Health made the next one harder to launch. Internally, we call it the "Innovation Tax". Launching a program meant touching dozens of services, each with its own assumptions about what a "program" was and each with program-specific logic scattered throughout the stack. By early 2026, the mobile app alone had roughly 400 files with program-specific conditionals.
That model worked when there were only a few programs. It does not scale well when you want to support a broader set of care journeys across different conditions.
So over the prior year, our teams worked tirelessly to rework the underlying model. The goal was simple: move from hard-coded program logic toward a more configurable system that could support new programs without requiring every team to rebuild their part of the product from scratch.
The architectural shift
The model that emerged is called Problems, Programs, and Components (PPC).
A Problem is a clinical condition: migraine, chronic back pain, knee osteoarthritis. A Program is a container that groups a Problem with a set of Components: Exercise Therapy, Education, Device (Enso), Care Team, Tracking. Components are the building blocks of the member experience, and each is owned by a single domain team, providing the necessary loose coupling between domains, programs, and problems.
The decoupling between Problem and Program is deliberate. In the legacy model, "Program" was just an identifier, like Chronic, Acute, that downstream services keyed off in conditionals. The real container was the Pathway, tightly bound to its Indication (the clinical condition, e.g., "lower back pain"). PPC promotes Program from a label to a configurable container, loosely coupled to the Problem. That's what lets a Program be configuration rather than code.
The key shift: program behavior is no longer encoded as conditionals inside each service. Instead, a central configuration service knows which Components a Program includes and exposes that configuration to every downstream service. When a member enrolls in the Migraine program, the configuration service tells the exercise service "this program has an Exercise Therapy component with this configuration," and the exercise service delivers exercise content. It doesn't need to know or care that the program is for migraine.
This means domain teams (exercise, education, care team, engagement) build their features once, for all programs. A new program launch becomes a configuration exercise: define the Problem, select the Components, configure the program-specific parameters within each Component. Since every program draws from the same set of Components, members also get a more consistent experience moving between programs: the same Exercise Therapy or Care Team interactions, just configured differently.
In the simplest of terms, we spent a year building a platform that makes future launches easier, safer, and more repeatable.
Migraine was the first major proof point.
What the migraine team actually had to build
That platform work gave the migraine team permission to stay focused.
The dedicated team included two fullstack engineers, a PM, and an engineering manager, and their scope was intentionally narrow: build only what migraine required that the platform could not already provide.
That meant focusing on migraine-specific capabilities such as:
- migraine tracking, including episodes, triggers, symptom journals, and trend visualization
- support for Enso for migraine, including a new waveform, forehead pad placement, and a distinct contraindication flow
- migraine-specific exercise therapy
- problem-based education content
That work supported a broader care experience, which delivers rapid drug-free pain relief, personalized trigger management, and expert-led prevention for migraine sufferers.
What the platform already handled
Just as important is what the team did not have to build from scratch.
Because of the platform work, the migraine launch could inherit core capabilities including enrollment, onboarding, engagement systems like points and streaks, billing, and dynamic home screen and library experiences.
That is the real story behind this build.
The speed did not come from cutting corners on a clinically sensitive launch. It came from reducing the amount of net-new engineering work required for each new program.
What we learned
Migraine also validated something important about how we want to build at Hinge Health.
Even with a stronger architecture, launching a new program still involves real engineering judgment. The team encountered a few legacy dependencies and interim workarounds along the way, but the broader direction held: make pragmatic decisions that preserve the long-term architecture instead of adding debt everywhere.
"We moved fast" undersells it. The truth is that we're getting better at doing hard things in a way that holds up over time.
The trade-offs we actually made
An architecture diagram is one thing. Shipping software on a predictable timeline is another. The migraine launch required several deliberate trade-offs.
- When a new concept doesn't fit into a legacy system already slated for replacement, sometimes the right move is a bridge that's deliberately loud and obvious, not a clean abstraction, so it never gets mistaken for permanent.
- Old and new systems don't always need to fully reconcile before launch. When a downstream service still expected data in the old format, the new concept was mapped onto it as a stopgap while the real migration continued in parallel.
- Building something genuinely new can expose assumptions the platform didn't know it had. Migraine needed a distinction the original model hadn't planned for, and once that gap was visible, the fix was a small addition to the model, not a rework.
Each of these was a deliberate choice: build a well-understood bridge that doesn't compromise the architecture's direction, ship on time, and clean up in the next cycle. The architecture gave us a target state. Knowing which bridges were safe to build, and which would create compounding debt, was the real engineering judgment.
Why this matters for engineers
For engineers, this is the kind of work that is especially rewarding.
You get to build systems that matter to real people. Migraine affects one in six American adults, with double the prevalence for women versus men, and Hinge Health's Migraine Care Program is designed to deliver comprehensive support through pain relief, trigger management, and prevention.
You also get to work on problems that are both technical and deeply cross-functional. Launching something like this requires platform thinking, product judgment, and close partnership with clinical and commercial teams.
That is what makes this story worth telling. We're invested in the right foundation, and that foundation is changing what is possible. Migraine was our first expansion. It won't be our last.
