A medical reference platform for hair restoration, designed, built, and shipped to production. The hard part wasn't the interface. It was building trust into a field with no authority to borrow it from, and keeping it intact when the engineering arrived.
A medical textbook that lives on the web.
Trichopedia is a reference platform for hair loss and hair restoration surgery, written and peer-reviewed by physicians. Think of it as a textbook that lives on the web, stays current, and says on every page who wrote it, who reviewed it, and when.
It carries six kinds of material: evidence-based articles at its core, an atlas of labelled clinical photographs, real patient cases followed from presentation to outcome, lecture and surgery videos, short summaries of newly published research, and a library of citations to the primary literature.
It serves two audiences, weighted equally. Physicians, who both write and read it. And patients, who arrive from a search engine with a specific worry and need to understand what they're reading, and trust it.
02 / THE PROBLEM
A field with no source of truth.
The reason it needs to exist is a trust vacuum. Hair restoration has no single trusted reference and no recognized governing authority. The field's main board isn't recognized by the medical establishment the way other specialties' boards are, and the largest professional society covers only about a third of practising physicians. There is no institution a new platform can borrow credibility from.
Meanwhile the stakes are rising. A newer technique lowered the barrier to entry so far that an estimated thousand procedures a day are performed in Turkey alone, many in clinics with no physician present. Patients researching a surgical decision are left with Google, clinic sites whose before-and-after photos are easily faked, paywalled journal papers written for specialists, and forums where one bad outcome gets written up at length and a million ordinary ones never do.
So the design problem wasn't "make a medical wiki." It was: build a platform that is visibly, structurally trustworthy, when there's no authority to inherit trust from. It has to manufacture its own.
03 / TWO AUDIENCES, SERVED EQUALLY
The platform fails if physicians don't contribute.
Most reference sites optimize for readers. This one has two audiences that had to be weighted equally, and that decision shaped everything.
Physicians are both the writers and the readers. If they don't contribute, there is no platform, which makes the contributor experience a primary design surface, not an afterthought bolted on behind a login. Patients arrive from a search engine with a specific worry and need to understand what they're reading and trust it fast.
Designing for both at once meant the same page had to work as authoritative clinical reference and as something a frightened patient could parse. That tension runs through every template in the platform.
04 → BUILDING TRUST
If you can't borrow trust, you build it into the page.
The platform's entire argument is that it can be trusted. With no institution behind it, that argument had to be made structurally rather than asserted.
Every piece of content, an article, an atlas image, a case, a video, carries the same metadata header: author, version, editors, published date, last updated, last medically reviewed, and a citable identifier. The provenance is on the page, not in an "about" footnote. Articles say plainly when they've gone stale. And when new research has been published since an article's last review, it appears above the article, not below, because a reader about to act on out-of-date information needs the correction first, not eventually.
An early version had drifted into four different provenance treatments across the four content types. I replaced them with one shared component, so the trust apparatus reads identically everywhere. Consistency is itself a credibility signal: a platform that presents its sources differently on every page looks improvised.
05 → RESEARCH
I refused to design against placeholder text.
The engagement began with a structured pre-work exercise and a recorded discovery session, and one request did more for the design than anything else.
Rather than send the client a form to fill in, I designed and deployed a purpose-built web form for him to complete over a week, with autosave, because losing his input was the failure mode that mattered. The central ask was this: pick the condition you explain most often, and write the page you wish existed for it. Don't format it. I wanted to design against real clinical prose, because placeholder text makes every layout look good, while real content is longer, denser, and more awkwardly shaped, and it shows you where the design has to work harder.
That produced templates built against genuine clinical writing from day one. The discovery session then overturned assumptions in the original brief. The belief that physicians look things up quickly between patients, for instance, was simply wrong: between patients is chaos, not study time. So the platform stopped optimizing for speed of lookup and started optimizing for material that survives being found, saved, and returned to later.
06 → DESIGN DECISIONS
Built both, measured, let the evidence decide.
A recurring pattern in this project: when a design question came up, I built the alternatives and measured, rather than defending a preference.
The knowledge-base articles had a sticky contents rail. The client wondered if the page was better without it, so I built a second version, at a second address, with a toggle to flip between them. Measuring revealed something neither of us expected: removing the rail didn't widen the text at all, because the prose was capped at the same measure either way. What changed was position, not readability.
I'd initially reasoned the freed space should be used to center the body, balanced margins look intentional, a gap looks unfinished. Measurement reversed me. Centering pushed the prose 149 pixels inside its own title, aligned with nothing, while the breadcrumb, title, and metadata all began at the same left edge. With the rail present, that indent had a cause. Without it, none. I caught it by asking the question and measuring the answer, not by trusting the aesthetic instinct, which was wrong.
The same discipline settled capitalization (sentence case, applied at display time, because the stored values double as filter keys and capitalizing them would have broken filtering silently), image annotation behavior (enlarge in place rather than trapping the reader in a modal, which also avoided a WCAG 2.2 failure), and more. Decisions traced to measurement, not taste.
07 / FROM PROTOTYPE TO PRODUCTION
The prototype proved the design. Then I built the real thing.
The prototype did its job: it validated the design against real clinical content and client review. But a validated design is still a picture until it runs. So I built the production application underneath it.
That meant a real system, not a demo. A Postgres database, real accounts and sign-in, file storage, email, server-side permissions on every action, and an audit trail recording every review decision, which matters in a product whose entire premise is a defensible record. Physicians submit, review, and publish inside a running application on infrastructure the client owns, and I run the releases, the database changes, and the fixes on it.
I don't hand-write the code. I direct AI development and own every decision, spec, and release, and I hold the build to the discipline a real team would. Every change runs through an automated test suite before it can ship: integration tests against a real database, browser tests across two engines, an accessibility check, all gated in CI so the release is blocked if anything fails. Code standards are enforced automatically. Releases are versioned and changelogged. Database changes are dry-run before they touch live data, and the system can be rolled back in a minute. Before the pilot opens to physicians, an independent security review is planned.
The application is built and readied for a closed physician pilot. It isn't open to real users yet, and I'm not going to imply it is. What's true today is that the design is no longer a prototype. It's a running product with a real backend, built and operated by one person, to a standard that holds.
08 / AI AND TRUST
The whole product is provenance. AI is the thing most likely to break it.
Trichopedia's entire value is that you can trust what's on the page: who wrote it, who reviewed it, when. Adding AI to a product like that is dangerous in a way it wouldn't be elsewhere. The thing AI is good at, generating fluent, confident text, is exactly the thing that erodes a provenance-based product if it's let in carelessly. So before any model was connected, the design work was deciding the rules AI would have to live under.
The principle underneath all of them: AI assists the people who are accountable. It never replaces them, and it never acts as the authority.
That turned into concrete decisions. AI checks, it doesn't gate, a model can flag a concern, but it can't block or approve publication. The author decides, always. AI asks questions rather than making changes, it surfaces "should this be clearer?" rather than silently rewriting clinical text. Anything AI touches is disclosed. The rules it runs under are versioned, so a change in behaviour is traceable. The model is chosen by measurement, not by brand. And the system fails open: if the AI is unavailable, the human workflow continues unblocked, because the people were never the fallback, the AI was.
The decisions I argued against are as telling as the ones I kept. An early proposed approach would have let a confidence score gate whether content could be published. I pushed back: a number shouldn't be able to override a physician, and a product that lets it stops being physician-authored in any meaningful sense. Another would have routed unpublished clinical text through an external service, I rejected it rather than let in-progress medical writing leave the system.
To be clear about status: no AI model is connected today. What exists is the design framework, the architecture, and the labelled stand-ins where the AI will plug in. This section is the thinking, not a shipped feature. But in a high-stakes medical product, the thinking is the hard part, and getting the rules right before the model arrives is the difference between AI that supports trust and AI that quietly dissolves it.
09 / REFLECTION
What I'd do differently, and what's still unsolved.
The research rested on a sample of one.
Everything the design assumes about how physicians work rests on a single physician, who is also the client, and therefore the least neutral source available. The project's own requirements flagged this in writing, recommended talking to two or three other physicians, priced it as cheap, and it never happened. I'd fight harder for that next time. A platform whose entire premise is credibility shouldn't be designed against one voice, however expert.
Half the audience was designed at second hand.
Patients are one of the two equal audiences, and not one was spoken to. Their needs were inferred from the client and from research about the field, which is real evidence but not the same as watching a frightened person try to read a clinical page. That's the gap I'd close first.
The sharpest opportunity in the brief is still unsolved.
Patients believe a common medication's side effects are near-universal, when the real rate is one to two percent. Representing prevalence against anecdote, credibly and visually, was one of the clearest chances to outperform every existing source. A panel for it was built and then removed. There's currently no answer to it on the site, and it's the thing I'd most want to revisit.
The method's biggest risk is the method itself.
With effectively all code AI-written and no traditional test framework, verification leaned on browser-driven measurement scripts. Two of those scripts had silent failure modes that let them report success when they hadn't checked properly. In a directed-build workflow, the verification is load-bearing, and verification you can't trust is the single riskiest thing about the approach. Next time, I write the checks that check the checks.