PolicyGap — Plain-Language Insurance Coverage Clarity

The idea came directly out of lived experience, working as a temp in an insurance office while studying for my P&C license. I watched how genuinely confusing policy documents are for the people who actually hold them. Coverage language is written for adjusters and agents, not the person paying the premium, and most consumers have no simple way to answer basic questions about their own policy without calling someone whose job is, at least partly, to sell them something.

That gap, a policyholder wanting a plain answer without a sales conversation attached, didn't have a neutral tool built for it.

Design and build, end to end, a tool that takes a real insurance policy, however messy the source, and returns a clear, honest answer to the five questions that actually matter to a policyholder: coverage area, what's covered, what's not, the deductible, and how to file a claim. It also needed to tell someone whether their coverage looked adequate, at minimum, or more than sufficient, without ever crossing into recommending a specific policy, product, or agent.

Working solo, I owned research, information architecture, UI design, prompt design, and front-end build.

Domain research came first. Time spent in an actual insurance office and studying licensing material directly shaped which fields mattered. The five-point structure isn't arbitrary, it's what policyholders actually ask about, filtered from what's mostly noise to a layperson.

Input flexibility was a deliberate accessibility decision. Not everyone has a clean PDF of their policy; many people only have a photo of a mailed paper copy. Supporting both photo upload and pasted text meant the tool worked for how people actually hold their documents, not just the ideal case.

Trust required a restraint principle, held firm. Because financial and legal understanding is high-stakes, I made an early product decision to never surface a recommendation, agent referral, or policy suggestion in the output, only an explanation of what the person already has. That boundary is the entire reason the tool can be trusted to give a neutral read rather than a sales funnel wearing a helpful mask.

Trust also required saying the boundary out loud, not just building it in. I wrote explicit, visible language on the site stating that PolicyGap is an education tool, not a lead generator. It is not selling anything, is not affiliated with any agent or insurer, and its output should not be used as the basis for a financial decision. That disclosure protects the person using it from over-trusting an AI-generated summary, and protects the integrity of the tool itself from ever being mistaken for a sales channel.

AI extraction demanded transparency, not black-box confidence. Because the tool interprets real policy language via the Gemini API, the interface is designed so the output reads as an explanation grounded in the source document, not an authoritative verdict. Each extracted field carries a confidence signal, encouraging the person to verify low-confidence fields against their actual policy rather than treat the summary as a replacement for it.

Built and shipped independently, using Claude and Cursor for development and Vercel for deployment: full-stack ownership from concept to live product.

PolicyGap v1 is live at policygap.insure and gathering its first users and real-world feedback.

Try it yourself with a real policy, a photo or pasted text is all it takes, and if you have feedback, I'd genuinely like to hear it. Find me on LinkedIn.