On July 29, the FTC — joined by California and Utah — filed a complaint against Hims & Hers. The allegations fall into three buckets: sharing users’ health information with advertising platforms like Meta and Snap through tracking pixels, charging customers shortly after they submitted an intake form despite messaging that suggested a provider consultation would come first, and making subscriptions hard to cancel. Hims & Hers disputes the allegations and says it will defend itself in court, and nothing has been proven. That process will play out over years.
But you don’t have to wait for a verdict to learn from the complaint, because whatever the legal outcome, it’s a map of three engineering decisions that every direct-to-consumer telehealth company has to make. We’ve made all three, repeatedly, in production. Here’s how we think about each one.
Decision 1: When does the charge fire?
The complaint’s most attention-grabbing allegation is that customers were charged right after intake, before speaking with a provider. The easy hot take is “never charge before the consult.” We think that’s the wrong lesson.
There’s a legitimate operational argument for charging at checkout. Processing a telehealth order costs real money before any medication ships: clinical chart review, asynchronous follow-up questions, identity verification, sometimes a synchronous consult. When a patient has no financial stake in the process, a meaningful share of them abandon mid-stream — after clinical operations time has already been spent. A patient who has paid is a patient who answers the follow-up message. That’s not a dark pattern; that’s aligning incentives so care actually gets completed.
The sin isn’t the charge timing. It’s charging at checkout without building the machinery that makes it honest: crystal-clear disclosure of when the card is charged, and — this is the engineering part — an automatic refund rail triggered by clinical rejection. If a provider declines to prescribe, the refund shouldn’t depend on the patient noticing, complaining, and winning an argument with support. It should be a system event: rejection posted, refund issued, patient notified. If you can’t build that rail, you haven’t earned the right to charge at checkout.
We have built both models. With charge-on-approval, the card is not charged until the medication is approved, and then on each subscription term. With charge-at-checkout, the automatic clinical-rejection refund ships as part of the build, not as a backlog item. Either model can be done right. The test is simple: is the architecture trying to take money from patients who don’t receive the product and outcome they came for? If the answer is anything but an unambiguous no, the funnel is broken no matter how well it converts.
Decision 2: How far does the tracking stack reach?
The pixel allegations are the ones that should make every telehealth CTO open their tag manager today. The complaint describes trackers from major ad platforms capturing user activity on a health company’s site.
Our position: the ad-tech stack stops at intake. Landing pages, product pages, and checkout can be instrumented much like any e-commerce funnel — with the significant exception that actual product and condition data should be obfuscated even there. “Purchased: SKU-2847” is a defensible event to share with an ad platform. “Purchased: [medication name for a sensitive condition]” is not, and stitching that to a user identity is exactly the pattern regulators keep targeting.
Once a user crosses from shopper to patient — the moment intake begins — third-party advertising and marketing pixels are off-limits. Full stop.
That does not mean flying blind past the paywall. Analytics and engagement tooling is a different category, provided a signed BAA is in place: that’s private data shared with a named business associate under a legal framework, not broadcast to an ad network’s audience-building machine. But a BAA is a floor, not a hall pass. Even with one signed, only critically necessary data should flow. The data your product analytics needs is not the same data your clinical operations need, and that separation should be explicit in your event schema — with the default set to don’t share whenever there’s doubt.
If you can’t diagram, today, which tools can see which events at which stage of your funnel, that diagram is your next sprint.
Decision 3: What does cancellation actually do?
The complaint describes a cancellation path buried behind multiple navigation steps and survey screens. Everyone will read that as “cancellation deflection is bad.” We’d sharpen it: cancellation deflection is bad when it serves the business instead of the patient — and the same mechanics can do either.
A patient starting a cancellation flow is telling you something. If the reason is cost, offering a discount is helping. If the reason is “I’m not seeing results,” offering a conversation with a provider is arguably the most clinically responsible thing your product can do — that patient came to you with a care concern that still exists. A cancellation flow is one of the highest-value moments to meet a patient where they are.
The line is control. The patient must be able to cancel at any time, and the cancel action must be findable, finite, and final. One genuine offer to help is patient support. A maze that makes “cancel” the hardest button on the site to reach is retention laundered as UX. If your flow would embarrass you read aloud in a federal complaint, it fails the test.
The real lesson: these are architecture decisions wearing marketing costumes
The common thread through all three allegations is that decisions with profound privacy and patient-trust consequences were, at some point, treated as growth decisions. Charge timing looks like a conversion-rate lever. Pixel scope looks like an attribution question. Cancellation UX looks like a churn metric. Each one is actually load-bearing architecture.
Growth teams aren’t villains — optimizing acquisition and retention is their job, and very private health data can absolutely drive more sales. That’s precisely why the room where these decisions get made needs more voices: compliance and privacy, and a clinical perspective, sitting as a check and balance so that privacy is treated as critical rather than as friction. And it needs engineers who understand that “where does the charge event fire” and “what does this pixel see” are system-design questions with regulatory blast radii, not configuration details.
Every D2C telehealth platform we build gets these three decisions made explicitly, on purpose, with the tradeoffs written down. If yours were made by default — by whatever the funnel template did out of the box — the H&H complaint is your prompt to go find out what they were.
Fanzoo builds and runs engineering for virtual-care companies — intake, prescriber workflows, pharmacy and EHR integrations, payments, and the compliance-aware plumbing underneath. If you want a second set of eyes on how your platform handles these three decisions, see how we approach HIPAA and security or start with a Launch Path.