Treating a Workflow Like a Product
100K returning users and 350M impressions in under a year.
Nearly every clinician in America who deals with documentation has Googled an ICD-10 code.
Not because they want to. Because they have to.
ICD-10 codes are the shorthand that turns messy clinical reality into something insurers can process. Symptoms, diagnoses, laterality, billable variants, edge cases. The lookup behavior around that work is enormous, repetitive, and invisible if you’re not in the workflow.
For nearly two decades, much of that demand has flowed through icd10data.com — millions of visits a month, comprehensive, and mostly unchanged.
The incumbent was static: it stored the information, but clinicians still had to do the work. The opportunity was turning a directory into a tool.
Freed, an AI company focused on clinician happiness, asked me to build what was, at first, basically an awareness wedge for clinicians. I said yes and got a first version live in under a month.
What made it work, though, was realizing it couldn’t feel like marketing. It had to solve a time-critical workflow on its own terms.
I’d never looked up an ICD-10 code in my life. At first that felt like a disadvantage. In practice, the distance helped. I didn’t come in with industry assumptions. I came in with a simpler question:
Why does a workflow this frequent still feel like a static directory instead of a product?
What I Built
On the surface, icdcodes.ai is a code lookup tool. In practice, it compressed the workflow into as few steps as possible.
Clinical documentation rarely happens in ideal conditions. That became obvious fast once I started watching how clinicians actually used the tool — between patients, on their phones, half-distracted. In that context, speed isn’t a nice-to-have. It is the product.
I didn’t get that right immediately. In early conversations, clinicians lit up at the idea of richer, diagnosis-first documentation: detailed pages around each condition. I initially took that as the wedge.
But when I put an early version in front of people, the mismatch showed up fast. I watched one clinician say the diagnosis pages were great, skim a page for a few seconds, then jump straight to searching for a code. Then four more codes in the next twenty seconds. The richer content got compliments. The lookup box got used. When someone needed an answer, they didn’t want a mini-reference experience. They wanted the right code, fast.
Once that became clear, the product shifted.
Almost every decision from then on collapsed into the same constraint: the right code, fast.
A simple example was knee pain. If someone typed “left knee pain,” they wanted the left-knee code immediately. If they typed “knee pain,” they might not know the laterality yet, or the note in front of them might not specify it. The right move wasn’t to make them type more. It was to surface left, right, and unspecified immediately so all they had to do was click.
That logic shaped the whole system. It had to understand how clinicians actually searched: partial terms and half-remembered codes.
Early in the build, I watched the model return a confident, cleanly formatted code that was one digit off from valid. Not a hallucination — a near-miss. That kept happening: left instead of right, unspecified instead of specific, a code that looked plausible but wasn’t billable.
45-year-old female fell on outstretched left hand yesterday. Left shoulder pain, limited abduction. MRI shows full-thickness tear of the supraspinatus tendon, left shoulder. No prior shoulder complaints.
Same body part, same side, same condition.
But M75 is non-traumatic; S46 is an injury.
That distinction determines whether this is treated as acute or pre-existing — and changes the reimbursement pathway.
It was tempting to treat model intelligence as the center of gravity. In practice, accuracy improved when more of the intelligence lived in structure: retrieval, hierarchy, matching, guardrails, presentation.
The model helped. But the model was not the product.
I eventually stopped letting the model provide code descriptions at all. It returned code numbers; the descriptions came from the official CMS dataset. That one decision eliminated an entire class of errors.
I also stopped trusting the model’s confidence signals. The model identified diagnoses from the input; a separate retrieval layer looked up the correct codes from the official hierarchy. The model told us what to look for. The structure verified what was correct.
I didn’t throw away the directory model clinicians already knew — I kept the familiar structure and layered intelligence on top of it.
Why It Grew
I didn’t build a marketing site and later “do SEO.”
The structure of the product was the growth strategy.
ICD-10 already contained its own distribution map: roughly 70,000 codes, plus every synonym, category, and related condition people actually searched for. The real job was building a product whose architecture matched it.
The site had to look like a large, structured corpus to Google and behave like a utility to clinicians. Every billable code got its own page, each category linked to its children, and every synonym clinicians actually searched became an entry point. The data already had the shape — the site just had to mirror it. It also had to be fast enough that going from query to answer felt immediate.
Around six months in, the compounding became hard to ignore. Organic visibility kept climbing. I still remember the first time I opened the graph and realized this wasn’t a spike. The floor had moved.
350 million organic impressions in under a year, no paid acquisition. 40 million last month, still growing 10%+ month over month.
More importantly, people kept coming back. Over 100K returning users. Visibility is one thing. Choosing to come back is another.
What Turned Out to Matter
The project was always Freed’s to own, which felt right. Not every good build is meant to be yours forever. Timing helped too: the tooling had crossed the threshold where one person could move this fast, and the incumbent had stayed still long enough for the gap to matter.
What stayed with me wasn’t the number. It was the shape of the opportunity: millions of searches, tens of thousands of codes, one stale directory people tolerated, and a workflow so common it had become invisible.
The traffic graph was just the visible proof of something simpler: clinicians were doing the same annoying thing, over and over, and the dominant experience had never been treated like a product problem.
A lot of those workflows still haven’t been.