Compliant Revenue Model Design: Where the Margin Lives

The Pricing Structure Was the Legal Risk, Not the Product

In a regulated marketplace, the difference between a clean business and a federal anti-kickback problem is almost never the product. It's whether your margin moves with the volume or value of what gets prescribed.

I learned this building the revenue model for a longevity and telehealth membership. The product was fine. The clinical model was fine. The thing that could have sunk the entire company was a single design decision most founders make in five minutes on a pricing page.

Here's the buyer's real question, the one nobody says out loud: how do you make money in a regulated space without the pricing structure itself becoming the legal problem? Because the obvious moves (bundle the meds into a tidy monthly fee, take a little margin on the prescription) are exactly the moves that get you a letter from a regulator.

Compliant revenue model design is the part of this work that doesn't show up in the demo. It's the plumbing. And in regulated industries, the plumbing decides whether the whole thing is viable.

So I architected the revenue model around two fixed-dollar earning points and zero-markup pass-throughs. The goal was specific and unglamorous: the company's income literally cannot vary with the scripts written. Not "shouldn't." Cannot. Enforced in code, visible on the receipt, provable in the books.

That's the bar I want to hold this to. Not a pricing page that looks compliant if you squint, but a money flow where the incentive to over-prescribe has been engineered out of existence.

I'm not a lawyer. The legal team set the guardrails. My job was building a model that physically can't drift across them. This article is how that gets done.

Why Bundling or Marking Up Medication Is the Classic Red Flag

Anti-kickback and fee-splitting rules exist to kill one thing: a financial incentive to prescribe more, or prescribe pricier. Every classic red flag in telehealth pricing traces back to that.

The two pricing traps: bundled flat fee vs markup

There are two ways founders walk straight into it.

The bundled flat fee trap

You decide to sell one clean number. Membership plus medication, $X a month, everything included. Conversion loves it. Customers love it.

The problem is what happens to your margin underneath. If your costs for the included medication are lower than the flat fee, your profit grows every time more drugs get filled, or higher-cost ones get prescribed. Your income now scales with prescribing volume.

That's the exact incentive the anti-kickback statute is built to prevent. You didn't intend it. The architecture created it anyway.

The markup trap

The second version is more honest-looking and just as dangerous. You pass the medication through, but you add a margin. Ten percent, a handling fee, whatever.

Now your income scales with the value of what's prescribed. A more expensive prescription makes you more money. A prescriber who upsells makes you more money. You have built, in dollars, a reason to want pricier scripts.

This is anti-kickback safe pricing turned inside out. The markup isn't a pricing detail. It's a structural incentive that an auditor can read straight off your P&L.

Here's the part founders miss: this is an architecture problem disguised as a pricing decision. It feels like a number you choose. It's actually a property of how money flows through your system.

To be clear about my lane: I'm not interpreting the statute. The legal team drew the line. I built a model that can't cross it even by accident, which is a different and very buildable thing.

The Fix: Earn in Exactly Two Fixed Places

The model earns money in exactly two places. Both are flat dollar amounts. Neither moves with the prescription.

Two fixed earning points produce identical revenue regardless of prescription

A flat membership fee

A fixed monthly membership. Same price for every member, regardless of what they're prescribed or whether they're prescribed anything at all. This is the access fee. It buys the relationship, not the drugs.

A fixed per-order facilitation fee

A fixed dollar fee per order, charged for the work of facilitating that order. The key word is fixed. The same amount whether the order contains one cheap item or three expensive ones.

That invariance is the entire design. Let me show it with round numbers.

Say membership is $40 a month and the facilitation fee is $15 per order.

• Member A fills one inexpensive generic. Company revenue: $40 membership + $15 facilitation = $55.
• Member B fills three expensive medications in a single order. Company revenue: $40 membership + $15 facilitation = $55.

Identical. The company makes the same $55 whether the order is worth $30 or $900 at the pharmacy. Income is decoupled from prescribing, completely.

This is what regulated marketplace margin should look like. The margin lives in fixed fees for fixed services, never in the prescription itself.

The fixed amount is enforced in code. It's deterministic. No model decides it, no rep adjusts it per order, no checkout flow nudges it based on cart value. This is exactly the kind of logic that should never touch an LLM, the same principle I wrote about in letting the code do the math. AI can help a patient understand their plan. AI does not get to set the fee, because a fee that can vary is a fee that can drift across a legal line.

Two earning points. Both fixed. Both in code. That's the whole revenue model, and the simplicity is the point.

Medication and Consults Are Pass-Throughs, Not Revenue

Everything else the customer pays is a pass-through, not revenue.

Pass-through money flow vs revenue on the P&L

The medication cost and the clinical consult are recorded as pass-through liabilities. Money collected for the drug flows to the pharmacy. Money collected for the consult flows to the prescriber. The company never books a margin on either.

That's the pass-through billing model in one sentence: you collect on someone's behalf and remit it, and it never becomes your income.

So the P&L shows only two lines as revenue, membership and facilitation. The medication and consult dollars move through the company as liabilities and out the other side. They never touch the revenue line.

This is the part that turns a clean pricing page into actual compliance. The financial records themselves become the proof. An auditor reading the books sees, line by line, that company income does not move with prescriptions. The structure isn't a claim on the website. It's a fact in the ledger.

Which means the bookkeeping discipline is non-negotiable. You have to separate collected-on-behalf-of funds from earned revenue at the moment money comes in, not reconcile it later. If a pass-through gets miscategorized as revenue, even by accident, you've quietly recreated the markup trap inside your own accounting. The pricing page can be perfect and the books can still betray you.

So I designed the data model so a pass-through can never be classified as revenue. The two are different object types from the moment a charge is created. There's no code path where consult money lands in the revenue bucket. You can't fat-finger it, and a future engineer can't accidentally route it wrong, because the system doesn't offer the wrong route.

That's the discipline. The pricing structure and the data model have to tell the same story, or the story isn't true.

The UI Surfaces the Compliance Proof Instead of Hiding It

Most regulated checkout flows hide their fee structure to improve conversion. We did the opposite, on purpose.

Transparent three-line checkout receipt

The "what you pay" screen shows three lines, always separate, never bundled:

• Membership fee (fixed)
• Facilitation fee (fixed)
• Medication plus consult (pass-through, varies)

A single combined number would convert better. Everyone in DTC knows this. I run a DTC fashion brand; I've watched bundled pricing lift conversion in plenty of places. One clean total reduces friction.

We didn't do it. The separation is the entire point.

Keeping the three lines apart makes the fixed-fee invariance visible to everyone who reads the receipt. The customer can see the membership and facilitation fees don't change when their medication does. The auditor sees the same thing. The compliance story isn't buried in a finance system nobody outside the company can read. It's printed on every checkout.

There's a real argument here that I keep coming back to: when your compliance story is true, let the customer see it. Transparency is only painful when you're hiding something. If the fixed fees genuinely don't move with prescriptions, showing that is a feature, not a leak.

The buyer's instinct, the skeptical operator reading this, is that regulated UX exists to obscure pricing. Usually that instinct is right. Healthcare checkout is famous for hiding the ball.

So inverting it does double duty. It builds trust with the customer, because they can see exactly what they're paying for and why. And it builds the compliance record into the product surface itself, where it's hardest to fake and easiest to verify. The thing that makes the model defensible is the same thing that makes it honest.

How to Stress-Test Whether Your Model Actually Holds

You can run this test on your own business this afternoon. You don't need me to do it.

The one-question stress test and where models leak

The one-question test

Ask one question: does any line of our revenue change if a patient is prescribed more, or prescribed something more expensive?

If the answer is yes anywhere, the model has a leak. That's it. Every compliance failure in this category reduces to revenue that moves with prescribing. Find the line that moves and you've found the problem.

Where the model can quietly break

The leaks are sneaky because none of them look like a markup. Watch for:

• Volume-based facilitation tiers. A facilitation fee that rises with the number of items in the order. Now you earn more on bigger prescriptions. Leak.
• Percentage processing fees. A payment fee calculated as a percent of cart value. The bigger the medication bill, the more you keep. Leak.
• Per-prescription marketing arrangements. Any deal where you or a partner gets paid per script written. This is the textbook fee-splitting telehealth problem.
• Discounts that become markups elsewhere. A "free" consult that's quietly recovered through a higher facilitation fee on certain drugs. The margin just moved; it didn't disappear.

Any one of these reintroduces the incentive the whole structure was built to remove.

I'll be honest about my role again, because it matters here. This is the part where you need real counsel. I'm not the person who tells you the model is legal. My job is making the build match the legal constraint exactly, so that when your lawyers draw the line, the system can't cross it.

Run the one-question test before launch, not after. This is basic diligence for any operator building in a regulated space, and it's a lot cheaper than refactoring under a regulator's deadline.

Designing the Money Flow Before You Design the Funnel

Here's the lesson I'd hand any founder building in a regulated marketplace: the revenue model is an architecture decision, and it has to be settled before the funnel, the pricing page, or the checkout.

Get it wrong and you're not fixing a feature after launch. You're refactoring a federal-risk problem while live, with real patients and real money already flowing through the broken structure. That's a very different conversation, and a much worse one.

This is the same shape I've seen across every regulated industry I've rebuilt on AI. Financial advisory, labor compliance, payments, healthcare. The flashy part is never the part that decides viability. The unglamorous plumbing (how the money is classified, where the margin lives, what counts as revenue versus a pass-through) is what determines whether the whole thing is even allowed to exist.

In telehealth, I settled the money flow first. Two fixed earning points, zero-markup pass-throughs, separated on the receipt, enforced in code. Then we built the funnel on top of a structure that was already sound. The pricing became an asset instead of a liability, because we treated it as architecture instead of a number on a page.

If you're building in a regulated space and you're genuinely not sure whether your pricing structure is the asset or the liability, that's exactly the kind of problem I architect from the money flow outward. Not the marketing first. The money classification first, because everything downstream depends on it.

Ready to bring AI leadership into your company?

I work with a small number of companies at a time. If you're serious about AI, apply to work together and I'll review your application personally.

Apply to Work Together