Move Slow and Fix Things: Constraints on Launching a Healthcare App
Twenty years of consulting and freelance work built a particular instinct in me: decide fast, act fast. A client needs a strategy, I give them one this week, not next quarter. That instinct served me well for two decades. It does not serve me well with my two healthcare apps, Cariva™ (a caregiver app) or Genura™ (an app to support people who have just had knee-replacement surgery).
I'd love to launch both. Cariva™ lets caregivers coordinate with care team members through direct messaging. Genura™ lets patients upload pre-op and post-op paperwork to track their own recovery. Both features are exactly the kind of thing a typical tech launch would ship in a sprint or two. Neither is that simple. And the gap between my instinct and what these products actually require has been its own kind of design lesson.
What "move fast" assumes
The "move fast and break things" ethos only works if three things are true: being wrong is cheap, being wrong is recoverable, and the cost of being wrong lands on the company, not the user. A social app that ships a buggy feature can patch it Tuesday. A checkout flow with a confusing button costs a company some conversions until someone notices.
Image generated by ChatGPT
Healthcare inverts all three assumptions. Being wrong can be expensive in ways that aren't just financial. It isn't always recoverable — a missed message, a mishandled record, isn't something you patch after the fact for the person it affected. And the cost doesn't land on the company first. It lands on the patient.
Where the constraints actually bite
Cariva™’s messaging feature is the clearest example. A consumer chat feature is mostly a UX problem: how do you make sending a message feel fast and natural? A healthcare messaging feature involving care team members is a different category of problem entirely: secure transmission, access controls that determine exactly who can see what, and audit trails documenting who said what to whom and when. None of that is optional once real health information is moving through a message thread. I can't design the chat bubble before I've designed who's allowed to open the thread at all.
Genura™’s document upload has its own version of the same problem. Letting someone upload their own discharge paperwork for personal tracking is one thing, closer to a health journal than a medical record. But the moment that paperwork is being used to inform anything that looks like guidance back to the user — "your recovery seems off pace," for instance — the product edges toward something that could draw FDA scrutiny as clinical decision support, not just passive storage. The safe, simple version and the genuinely useful version of that feature aren't the same thing, and the distance between them is exactly where the constraints live.
Image generated by ChatGPT
Safety is the constraint underneath both of these, not a separate one. A wellness app that gets something wrong is mildly unhelpful. A healthcare app that gets something wrong — delays a message that should have reached a provider, mishandles a document that mattered — has a different order of consequence. That asymmetry is the actual argument for moving slower, not caution for its own sake.
Where fast still works
None of this means my instinct is wrong. Fast decision-making still serves me well in early concepting, in user research, in iterating on the parts of these products that don't touch protected health information: onboarding flows, symptom logging, the parts of Droma™-style tracking that stay in wellness territory. The instinct isn't the problem. Applying it uniformly across a product that has both low-stakes and high-stakes parts is the problem.
What this actually changes
I'm not scrapping the fast instinct; I'm learning to scope it. The realistic path for Cariva™ and Genura™ probably isn't one big launch. It's launching the parts that don't touch PHI (Protected Health Information) first — tracking, education, the wellness-side features — and moving toward the messaging and upload features once the compliance groundwork (secure infrastructure, access controls, the right legal review) actually exists underneath them.
That's a harder pitch to make to the part of me that wants to ship something this week. But it's the honest version of what launching in this category requires, and pretending otherwise doesn't make the constraints go away. It just moves the consequences downstream, onto someone who didn't sign up to be my beta test.
