How We Built an Evidence-Backed Directory for AI Email Assistants

Most software directories have the same failure mode: they look comprehensive, but the entries are thin rewrites of vendor landing pages. That is especially risky for AI email tools. A product may call itself an “AI email assistant” while doing anything from suggesting a single reply to autonomously triaging a shared support inbox. Pricing changes, provider support differs, and the privacy details matter because the software may read the most sensitive data in a company. We wanted a better way to compare the category, so we built AI Email Assistants, a focused directory generated from research dossiers rather than a hand-maintained list of cards. This is the process behind it and what we learned. Our first temptation was to build a broad AI-assistant directory. That would have given us a much larger pool of products and keywords. It also would have made the site less useful. “AI assistant” can describe a coding tool, meeting recorder, research agent, calendar app, or email client. A visitor cannot meaningfully compare those products. Email gave us a constrained problem with real buying questions: Does it work with Gmail, Outlook, or other providers? Is it an assistant inside the existing inbox or a replacement email client? Does it draft, triage, send, or act autonomously? Is it for a personal inbox, sales, or customer support? What does it cost after the trial? What email data does it retain or send to model providers? A vertical directory can answer those questions with a consistent data model. A broad directory usually cannot. We researched dozens of products before deciding what each card should show. Each product has a Markdown dossier covering the same broad areas: Product identity and current status Email-provider and platform support Core AI capabilities Pricing, limits, and trial terms Privacy, security, and permissions Best-fit use cases and important limitations First-party evidence Independent reviews and recent community signal The dossier is the source of truth. The homepage, filters, profile pages, and structured data are generated from it. That separation turned out to matter. It lets us improve the interface without rewriting the research, and update a changed price in one place instead of correcting several components. Vendor documentation is usually the best source for questions such as supported platforms, published prices, and official security claims. It is not independent evidence that the product works well. We therefore keep two evidence tracks: First-party evidence supports factual product claims. Independent evidence captures reviews, community feedback, and hands-on reporting. When independent evidence is sparse, the profile says so. Silence is better than turning two comments into a market consensus. This also exposed contradictions that a normal directory card would miss. A concise privacy page may say email content is deleted immediately while a full privacy policy permits retention in some circumstances. A feature page may advertise a capability that the pricing page still labels “coming soon.” A product may support Outlook, but reserve its best inbox-management features for Outlook while offering only drafting in Gmail. Those qualifiers often matter more than the feature list. Structured facts make products comparable, but they do not replace judgment. Two tools can both support Gmail, summarize threads, and draft replies while serving completely different users. One may be a privacy-focused desktop client; the other may be an autonomous support agent billed per resolved conversation. Each profile therefore includes a free-form review explaining: who the product is best for; what differentiates it; what would make us hesitate; where the available evidence is weak; and which buyers should look elsewhere. The structured fields help visitors filter. The review helps them decide. Our first implementation mistake was keeping too much of the work behind the scenes. We had detailed dossiers, but the public profiles felt bare. We changed the profile template to surface the useful parts directly: a full editorial review; product and platform facts; pricing and trial details; privacy and data-handling notes; current user feedback with an evidence-quality caveat; limitations; and linked sources. We also captured each product's public website at a consistent viewport and converted the screenshots to WebP. Screenshots make a directory much easier to scan, but treating them as data keeps the layout consistent and makes missing assets obvious. The public site is built with Astro and TypeScript. A data module parses the reviewed Markdown dossiers into typed product records. Astro then generates: the homepage directory; filterable cards; a profile page for each qualified product; canonical metadata; an XML sitemap; and ItemList, Article, and SoftwareApplication structured data where the facts support it. The filters are client-side view state and can be represented in URL parameters for sharing. We avoid generating indexable pages for every filter combination because those thin permutations would add crawl noise rather than useful search pages. We also added integrity tests. A qualified product must have a limitation, and the build cannot invent rankings, scores, or aggregate ratings that the research does not support. The Astro build was straightforward. The hard work was editorial maintenance. Several products share names with unrelated companies, common words, or old products. Search results and social posts can easily be attributed to the wrong entity. Exact domains, developer names, store identifiers, and official profiles are essential. Monthly and annual rates differ. AI features may be an add-on. Some vendors bill per seat, mailbox, automated resolution, or generated draft. A “starts at” price without its unit is often misleading. Established tools may have years of reviews that describe an older version. New products may have excellent documentation and almost no independent feedback. The profile needs to distinguish product maturity from research confidence. AIEmailAssistants.com is published by Inbox Zero Inc., which also makes Inbox Zero. We disclose that relationship on the site and on the Inbox Zero profile. Ownership does not disappear because a methodology exists, so readers should be able to see the conflict and inspect the evidence themselves. The directory is live, but it should not be static. The next useful layers are: hands-on testing with a published test protocol; correction requests from vendors and users; more direct screenshots of the actual product experience; historical pricing and feature-change tracking; and focused comparison pages only when they add real analysis beyond two copied profiles. The long-term advantage of a directory is not the number of entries. It is whether every new entry makes the dataset more useful and whether readers can understand why a claim is there. If you work on an AI email product, or use one we missed, you can suggest a listing or correction. I would also love feedback on the research model: what would you need to see before trusting a software directory with a purchase decision?