Building Products in Healthcare: What Nobody Tells You

The first healthcare product I built was an FDA-cleared CBT app for fibromyalgia patients. We prepared for the Quality Management audit. We designed HIPAA-compliant data flows. We documented every clinical protocol. That part was hard, but it was structured. We knew what the regulators wanted.What we did not know was how to make mindfulness exercises feel safe to people living in chronic pain. We did not know that pacing -- the speed at which patients moved through therapeutic content -- mattered more than the content itself. We did not know that a nudge to "keep going" could feel supportive to one patient and punishing to another.I have written about building in regulated spaces before -- the compliance architecture, the audit trail, the infrastructure decisions. That post covers the terrain. This one covers what the terrain does not prepare you for: earning clinical trust, designing for scared users, treating compliance as a creative constraint, and finding a business model when patient outcomes and revenue pull in different directions.## Clinician trust is earned, not purchasedMost healthtech products treat clinician involvement as a checkbox. Get an advisory board. Put logos on the landing page. Cite a study. Ship the product.At FLUXX Health, we built a menopause education platform with AI-driven phase detection. The clinical domain was enormous -- 150+ symptom types across hormonal phases, each with different implications depending on a patient's age, history, and current treatment. We could not build this alone. We needed clinicians not as advisors but as co-designers.We recruited a 20-member Clinician Advisory Board spanning OB-GYNs, nurse practitioners, urologists, naturopaths, and integrative medicine physicians across the US and UK. These were not people who reviewed our work once a quarter. They shaped the quiz logic. They reviewed AI-generated symptom explanations using a 5-step clinical validation process. They flagged when our language implied diagnosis rather than education. Dr. Aoife O'Sullivan, one of our UK-based clinicians, described the platform as "exactly what women need to understand" -- not because we got the medical facts right, but because we got the framing right.At Sperity Health, a longevity-focused wellness startup, I saw the same pattern. The founding team had a strong vision for biomarker-driven preventive care, but the product needed clinical grounding. We co-designed the Sperity Score -- a daily wellness metric combining Whoop HRV, Signos glucose data, biomarkers, and fitness evaluations -- directly with the physicians who would interpret it. The score only worked because clinicians trusted the inputs and the weighting. That trust came from collaboration, not from a slide deck.The pattern is consistent across every healthcare product I have built. Clinical credibility does not come from a logo wall or a medical advisory board that meets twice a year. It comes from genuine partnership -- from treating clinicians as domain experts who shape the product, not validators who bless it after the fact.## Patient engagement in health is fundamentally differentConsumer product teams often assume that engagement problems mean the product is not compelling enough. In health, the opposite is frequently true. Users disengage because the product is too compelling -- too close to something they are scared of.At FLUXX, our symptom assessment quiz had an abandonment problem. Users started the quiz and dropped off partway through. The initial assumption was standard UX friction: too many questions, confusing navigation, slow load times. We optimized for mobile, reduced question count, and streamlined the flow. Abandonment dropped by 38%.But the bigger insight came from user research. Some users dropped off not because the quiz was hard to use but because the questions surfaced symptoms they had been ignoring. A question about sleep disruption or mood changes could trigger anxiety about what the answer might mean. This was not a UX problem. It was an emotional design problem.We responded by building trauma-aware UX principles into the product. Symptom explanations normalized the experience before explaining it. The structure was always the same: here is what you might be feeling, here is why it happens, here are your options, here is the next step. We never led with a clinical term. We never framed a symptom as abnormal. Every piece of content acknowledged that the user might be encountering this information for the first time and might be frightened by it.Menopause, fibromyalgia, biomarker-driven wellness -- these are sensitive domains. The people using these products are often dealing with pain, confusion, or a body that has stopped behaving the way they expected. Standard engagement assumptions do not apply. In health products, the user's emotional state is as much a design constraint as screen size or load time. If you design for motivation, you will miss the people who need your product most. They are not unmotivated. They are scared.## Compliance is a design constraint, not a blockerNew healthcare product teams often treat compliance as a wall. They build the product first and then figure out how to make it compliant. This always costs more -- in time, in money, and in trust.The better approach is to treat compliance as a design constraint from day one, the same way you treat performance budgets or accessibility requirements. It shapes the product. It does not block it.At FLUXX, we designed a HIPAA-compliant URL tagging system called Track B. The problem was specific: quiz responses contained health information, and standard URL parameters would have exposed that data in browser histories, server logs, and analytics tools. Track B used token-based routing to prevent health signals from appearing in URLs. PHI stayed in the HIPAA-eligible AWS environment. No health data leaked into non-protected systems.This was not a compliance exercise. It was a product decision. Track B let us build a quiz that felt like a normal web experience while maintaining clinical-grade data handling. Users did not know it was happening. That was the point.At Sperity, we built HIPAA and SOC-2 compliant infrastructure on AWS from day one. The founding team initially pushed to move faster with consumer-grade tools. We ran a vendor compliance audit that flagged Google Sheets as a PII risk -- the team was tracking patient biomarker data in a shared spreadsheet. Moving to compliant infrastructure early meant we never had to retrofit. The FSA/HSA eligibility decision -- whether Sperity's services could be purchased with pre-tax health spending accounts -- required compliant billing architecture that would have been prohibitively expensive to add later.Every compliance requirement we met early became a feature we did not have to build twice. Every shortcut we avoided became a migration we never had to run.## The business model is harder than the productThe hardest conversation in healthcare product work is not about features or compliance. It is about money.At FLUXX, we developed over 50 monetization ideas across 7 revenue categories. We mapped 5 personas across hormonal phases, crossing each with potential revenue streams: phase-based wellness kits, a FLUXX Rx concept, employer wellness programs, clinician tools, data partnerships. The 360-degree Persona Activation Map was the most complex revenue modeling exercise I have run.The core tension was structural. FLUXX's users needed free access to education. Menopause information should not sit behind a paywall -- that was a values decision the founder and I agreed on immediately. But a B2C health product serving an underserved population cannot sustain itself on advertising or engagement metrics alone. The product needed B2B revenue: employer wellness contracts, clinician licensing, or institutional partnerships.At Sperity, the same tension appeared in a different form. The subscription tiers were straightforward, but FSA/HSA eligibility -- whether members could use pre-tax dollars -- changed the product's positioning entirely. An eligible product competes on value against gym memberships and therapy copays. An ineligible product competes against discretionary spending. The compliance decision was also a business model decision.This is the part of healthcare product work that nobody warns you about. You can build a product that works clinically, earns user trust, and handles compliance gracefully. And it can still fail because the business model does not support the population it serves. B2C health products that serve underserved populations almost always need B2B revenue to survive. The product work and the business model work have to run in parallel, not in sequence.## Why I keep doing this workHealthcare product work is not slower than other product work. It is more consequential. The constraints are real -- clinical trust, emotional safety, compliance architecture, business model tension. But those constraints produce better products. They force you to design with more care, listen more closely, and build infrastructure that actually protects people.Every healthcare product I have built has taught me something I could not have learned in a less constrained domain. The best product thinking I do today comes from building products where getting it wrong means something more than a bad review or a churned user.The work is hard. The constraints are heavy. The impact is worth it.---I build healthcare products that earn clinical trust and serve users who need them most. If your team is building in a regulated health domain and the product challenges go deeper than compliance, let's talk. You might also find my post on zero-to-one in regulated spaces useful for the infrastructure side.