A developer writing on dev.to has published an argument that the revenue model behind a health AI tool should be treated as an architecture decision, using the advertising-funded medical answer tool OpenEvidence as the entry point. The piece is a community opinion post rather than an audit: its OpenEvidence details are attributed to press reporting the author cites, and the author states he has not tested the product himself.
In the author's account, a January 2026 STAT report described OpenEvidence — which clinicians use to pose medical questions and get cited answers — as free for US clinicians who verify with a national provider number, with advertising as its main business model. Per the post, that same report also covers a $250 million raise. The author marks these funding details as drawn from press coverage, not from his own verification.
What the author asks, as an engineering matter, is whether an ad placed beside a medical answer might shape that answer. As he describes it, the company's advertising policy states that advertisers cannot influence the information provided, and that the ad system and the answer system are fully unconnected. On the status of that statement he is careful: it is the company describing itself, he writes, he has seen no independent test either way, and he is not alleging that a problem exists.
From there the post moves to what a developer should draw from the funding model. Where advertising is the revenue, the author's position is that a hard wall should separate the system that writes the answer from the system that picks the ad, with the answer generator never exposed to ad inventory. He adds that he would want that separation to be testable rather than taken as a promise.
Next, the three funding routes it names are contrasted in the post. Under a subscription model, the author reasons, the pressure moves toward keeping users happy and engaged; that, he says, can steer a product toward agreeable answers — and in health, he notes, agreeable is not always safe. Where a nonprofit or open reference source is the funder, he writes, money is thinner and updates can lag, though the pull to flatter the reader is weaker. His conclusion: none of the three is good or bad by default; what each one gives you is something to test.
The author also discloses his own product, Tabibu — described as a free health-information assistant that started in Kenya and sells paid Basic and Pro plans covering features such as document reading. Its safety rules, he says, take the form of tests: no diagnosis is issued by the tool, no result is called normal, and no dose is changed. As yet there is no clinician review, he states, and the site says as much. Any claim that his model is cleaner than anyone else's is one he explicitly declines to make.
A disclosure habit is what is concretely proposed — not a technical standard. In the author's view, any health AI should make visible who funds it and how a given answer was assembled, with that information placed alongside the response in ordinary language instead of being tucked into a footer most readers skip. The details he would have surfaced there are the provenance of the sources, whether money changed hands in connection with the content, and the boundaries of what the tool refuses to do. He closes by asking whether a medical answer should ever sit next to an ad, saying arguments on both sides are visible to him, and labels the post general information rather than medical advice.
For freelancers and developers building or integrating AI features, the useful contribution is the framing rather than any verified finding. The post suggests that when you assess a health AI tool, the funding model is a reasonable question to ask and a reasonable thing to design around, because it points to which failure mode to probe: ad-adjacent answers where advertising pays, agreeable answers where engagement-driven subscriptions pay, and stale content where thin nonprofit funding pays. That reading is editorial interpretation of the author's argument, not a tested result.
The reasoning behind that framing is worth separating from the claims it rests on. The author's inference is structural: whoever holds the purse strings creates pressure on the product, and pressure shows up in how the system is wired, whether or not anyone documents the choice. That is a plausible design heuristic, but the post offers no incident, measurement or comparison to show that any of the three funding models has actually produced the failure mode he associates with it. Readers should treat the mapping from revenue to risk as a hypothesis to check, not a demonstrated pattern.
The OpenEvidence example illustrates the gap between a policy statement and a verifiable property. A company can assert that its answer system and its ad system are unconnected, and that assertion may well be true, but from the outside it is indistinguishable from an untested promise. The author's proposed remedy — make the separation testable — is the part of the post with the most direct engineering content, even though he does not specify what such a test would look like, who would run it, or what evidence would count as passing.
There is also an asymmetry the post does not resolve. Advertising-funded tools face the question of whether commercial placement leaks into content; subscription tools face the question of whether engagement incentives soften answers; nonprofit and open-reference tools face thinner funding and slower updates. Each risk points at a different audit, which means a single disclosure format may not capture what actually matters for a given product. The author acknowledges this by saying each model tells you what to test, but leaves the testing itself undefined.
For a working developer, the practical takeaway is narrower than the headline question. If you are integrating a third-party health AI into a product, the post's framing suggests asking the vendor how answer generation is isolated from any commercial system, and whether that isolation can be demonstrated rather than merely stated. If you are building such a feature, it suggests writing safety behavior as explicit checks — the author's own examples are refusing to diagnose, refusing to label a result normal, and refusing to alter a dose — and disclosing the limits of the tool where users will see them.
The self-disclosure is relevant to how the post should be weighed. The author names his own product, Tabibu, describes its guardrails, and states that it has no clinician review while saying the site discloses that fact. He explicitly does not claim his model is cleaner than anyone else's. That candor is worth noting, but it does not convert his product claims into verified ones: the safety rules are described by their author, and no external evaluation is presented.
The limits are substantial and the author largely states them himself. The OpenEvidence details are secondhand press reporting as relayed in the post; the advertising policy language is the company's own description; and the author says plainly that no independent test of answer-ad separation has been shown to him. The piece contains no measurements, no audit methodology and no comparison data. Tabibu's safety rules are self-described, and the post says the product has no clinician review.
The post is therefore best read as a set of testable questions rather than a verdict. Its contribution is to name the link between who pays and how a system should be built, and to ask that the link be visible and checkable next to the answer. Whether any given product meets that bar remains, on the supplied evidence, unestablished.