← Back to portfolio
Case Study

Building InsightBridge: From Field Insight to Stakeholder Briefing

Independent Builder, InsightBridge · July 2026–Present
Live web app · AI-assisted build with Claude · Medical Affairs intelligence tool

InsightBridge is a working web app I designed and built that turns a Medical Affairs field observation, a clinical finding or a physician or KOL insight, into a structured, stakeholder-ready intelligence briefing. It grew directly out of a gap I kept running into while developing Women in Bio’s programming: field insight goes in, and nothing traceable comes back out.

The Need

Hosting Women in Bio’s “Measuring Impact in Medical Affairs” session surfaced a pattern I had already sensed: MSLs and other field-facing scientists gather real insight, clinical evidence, physician and KOL observations, and document it carefully, but it often disappears into a report no one visibly acts on. The activity is real; the impact isn’t traceable. That session named the problem. I wanted to see whether I could actually address it: build something that forces a field observation through the structure a stakeholder actually needs, is it new or a recurring pattern, what commercial factors does it touch for this specific product type, so the insight arrives as a decision-ready briefing instead of a note that has to be re-interpreted by whoever reads it next.

My Contribution

I defined the product from the ground up and built it using Claude as my development partner. The domain judgment was mine: what a Medical Affairs field insight actually needs to become useful to a stakeholder, and what distinguishes a well-formed briefing from a raw field note. I designed the input workflow around that judgment, product type first (diagnostic, pharmaceutical, vaccine, or medical device), because the commercial factors that matter shift by category; clinical evidence and an optional KOL or physician insight, so a briefing can rest on data alone or be sharpened by field commentary; whether the signal is a first report or a recurring one, because that distinction changes how a stakeholder should weigh it; and source or location, to keep the briefing traceable back to where the observation came from. I directed Claude through the implementation, the input form, the generation logic connecting each input to relevant business-impact factors, and the exportable output, while I tested and refined the actual output quality myself: writing the two built-in sample cases, running them through repeatedly, and rewriting the generation logic when a briefing came back generic instead of specific to the product type and signal status in front of it. That iteration, judging whether the output was actually stakeholder-ready or just plausible-sounding, was the real work, the same kind of judgment I apply reviewing a collaborator’s conclusions or shaping a program’s content.

What I Produced

A live, working web application, deployed at insightbridge-iota.vercel.app, that takes a Medical Affairs field observation through a structured intake and returns a stakeholder-ready intelligence briefing with business-impact mapping and PDF export.

Select product type → Enter clinical evidence + KOL insight → Flag first report vs. recurring signal → Generate briefing → Export as PDF

Built iteratively across 17 commits, including a small API layer behind the generation step and two built-in sample cases I wrote to validate and demonstrate the tool’s output.

Evidence

Live app: the working InsightBridge tool, including the built-in sample cases.

Source repository: the codebase and commit history behind the build.