How I Built The Signal by Refusing to Hand Doctors Another PDF

The views expressed here are solely my own. They do not represent the opinions, positions, or policies of any current or former employer, client, or affiliated organization.

For years I had a quiet, slightly uncomfortable habit. Whenever I scrolled past health content, I wasn't reading it for the advice. I was watching how it was built.

And what I kept noticing bothered me. The accounts spreading nonsense, the miracle cures, the fearmongering, the supplement grifts, were extraordinarily well made. Punchy hooks. Clean stories. A confident villain and a simple fix. Meanwhile the doctors who actually knew what they were talking about posted dense, careful, heavily-qualified paragraphs that nobody read to the end. The science was real and it was losing. Not because it was wrong. Because it was built badly.

I've spent a decade in content strategy and content supply chain, helping organizations turn complicated, specialized knowledge into something people actually absorb. So this asymmetry felt personal in a specific way: I recognized the problem. It was my problem, the one I'm paid to solve, just pointed at a field I had no business being in. And that left me with a question I couldn't put down.

Why does the side that's telling the truth keep losing to the side that isn't, and is the thing they're missing actually teachable?

That question, idle at first, is where The Signal began.

My first instinct was the wrong one, and I want to be honest about it. I assumed the answer was “doctors just need to learn to write better,” and that I could explain it to them. A few principles. Some before-and-afters. The kind of thing you put in a slide deck.

But the more I pulled on it, the less it behaved like a writing problem and the more it behaved like a systems problem, which is the shape of problem I actually know. The reason misinformation wins isn't better prose. It's that it's engineered, end to end, around how humans actually process information: what earns attention, what survives a scroll, what changes a mind versus what just informs it. Persuasion, applied ethically, is infrastructure. The people spreading lies had it. The people telling the truth didn't.

So I did what I do at work. I stopped looking for tips and started building the underlying structure. I went deep into the research on how people change their minds, and I started turning it into something repeatable, not opinions about good content, but a method. Who exactly are you talking to, and what makes that specific person resist or move? What is your actual voice, the phrases you'd use and the ones you never would? What do you stand for underneath the individual post? I built these into structured foundations, an audience portrait, a voice profile, a kind of brand document for a single physician, because content that doesn't start from those is generic no matter how hard you try, and content that does is suddenly unmistakable.

Somewhere in here, the project quietly changed shape. I hadn't set out to build a methodology. But that's what I had: a way to take what a physician knew and turn it into what a physician could say, in their own voice, calibrated to the people they were trying to reach.

Then I hit the problem that created everything that followed.

I wanted to teach this. That was the whole idea, give doctors the method, let them run with it. So I imagined the deliverable: a guide. A really good guide. The frameworks, the questions, the examples, all of it written up beautifully.

And I couldn't do it. Not because it was too much work, because I knew exactly what would happen to it. It would join the pile. The same pile of accurate, thorough, well-meaning material that physicians already don't have time to read between patients. I would have built, with great care, one more thing to be ignored. The very fate I was trying to rescue them from.

The method only worked if someone applied it rigorously to their own specific situation, their audience, their voice, their post. A static guide can't do that. It can explain the principle, but it can't sit next to you and apply it to the paragraph you're about to publish on a Tuesday between consultations. The knowledge needed to be usable in the moment, or it wasn't usable at all.

That was the realization that turned a methodology into a product. The AI wasn't a strategy. It wasn't a trend I was chasing. It was the only honest way to deliver what I'd built, the only thing that could take the method and apply it, live, to one doctor's actual words.

I'm a content strategist, not a developer. I want to be clear about that, because it shaped every decision that came after, mostly for the better.

I chose tools I could learn while building rather than the ones a real engineer would pick: Flask on a small Python host, a managed database, a large language model for the reasoning layer. Plain HTML and templates for the interface. No frameworks I'd have to fight. The whole point was that I could read an error message and understand what it was telling me, because I was going to see a lot of them.

And I did. The bugs were humbling and educational in equal measure. Logins that worked for new users and silently failed for returning ones because of an invisible mismatch in how a token was stored versus how it arrived. An auditor that kept showing “Error: undefined” for weeks because the backend and the frontend had quietly started calling the same thing by two different names. A mobile layout that looked fine on my screen and was unusable on the phone a doctor would actually hold. Each one taught me the same lesson from a different angle: the seams between systems, the handoffs, are where everything breaks, and the only cure is to make them explicit and test them on their own.

The piece I didn't see coming was trust. Physicians aren't a normal software user, they're professionally liable for what they publish and rightly cautious about patient privacy. So the tool grew a set of guardrails that I came to think of as features, not friction: plain-language notes on every field explaining what happens to that data, a scan that strips anything resembling patient information before it's ever stored, an acknowledgment that what the tool produces is a draft to think with, not medical content to publish blind. Building for someone who has more to lose than you do changes how you build. It made the product more honest.

The thing that started as me squinting at health posts is now a working tool. A physician sets up their foundations once, their audience, their voice, their purpose. From then on, the tool reads their draft and reflects it back across three dimensions: is it clear, is it persuasive, is it ethical. Not against some abstract standard, but against the physician's own stated way of communicating. It can pull usable, source-anchored content ideas out of a research paper. It can take a careful, dense, true paragraph and show the doctor how to make it land without making it dishonest.

Which is the whole point, restated: the science of persuasion doesn't belong to the people spreading misinformation. It belongs to anyone willing to use it responsibly. I just couldn't find a way to hand it to the people who needed it most, until the way turned out to be a tool that applies it with them, in the moment, instead of a document that explains it and gets filed away.

I went in thinking I was solving a writing problem for doctors. I came out having learned more about my own work than theirs.

The method was always the point; the software was just delivery. I spent a while thinking the auditor was the product. It isn't. The foundations, the audience portrait, the voice, the purpose, are the product. The tool is just how they get applied. A doctor who rushes that setup gets generic results forever; one who takes it seriously gets feedback that sounds like an editor who's read everything they've ever written. The intelligence was never in the code.

Not being a developer helped more than it hurt. Because I didn't have an engineer's instincts, I asked “why” constantly, and I never got attached to clever architecture for its own sake. Every decision got judged by one question: does this serve the physician? That's a worse way to write code and a better way to build a product.

Refusing to ship the easy version is sometimes the whole job. The guide would have been faster, cheaper, and safer to make. It also would have failed, quietly, the way good intentions usually do. The hard version existed only because I let myself be stopped by the question ‘but will they actually use it?’ instead of shipping past it.

The project that starts the journey is rarely the one you finish. I began by wanting to understand why bad medicine out-communicates good medicine. I ended up building infrastructure to even the fight, and learning that the thing I do for large organizations holds up just as well pointed at a problem I had no credentials to touch.

The Signal is an independent project, built to test where my own thinking about content holds up outside the work that pays for it. It exists to give evidence-based medicine the same communication infrastructure that misinformation already enjoys. That's not a product vision. It's a problem worth solving.