Sales research is mostly reading. You land on a company's website, click around the homepage, the about page, the product pages, and try to answer a few boring but essential questions: what does this company actually do, who is their customer, are they a fit for what I sell, and who should I email. Then you write the email. Then you do it again for the next company, and the next, until the tab count is a personal insult.
I built SignalizeAI to collapse that loop. It is a browser extension, shipped on both the Chrome Web Store and Firefox Add-ons, that turns a public company website into a usable prospect record. It has real users today, and this post is about how the pieces fit together.
The core idea
The unit of value is a prospect record. Point the extension at the site you are looking at (or paste any URL) and it runs a Quick Website Check, then presents the results in a tabbed insights flow: Strategy, Emails, and Snapshot.
The Strategy side generates the research a rep would otherwise assemble by hand: what the company does, a company overview, their value proposition, their target customer, a sales-readiness read, a recommended buyer persona, a likely goal, and an outreach angle. The Emails side turns that into something you can actually send: three different outreach approaches, one recommended email, and follow-ups.
The point is not "AI wrote an email." The point is that the research and the message come out of the same pass over the same source, so the email is grounded in what the company's own site says rather than a generic template with the company name pasted in.
How it works: the extension
The extension is Manifest V3, written in TypeScript, and bundled with esbuild. Manifest V3 shapes a lot of the architecture. There is no persistent background page, so the flow is built around message passing and a backend that holds the heavy logic rather than the extension trying to be smart on its own.
One detail I care about is that the extension does not blindly re-analyze. If you have already saved a prospect for a website, it shows the saved analysis by default instead of burning a fresh run on a site you have already researched. Every saved or unsaved analysis can be opened on the web app through an Open in website action, so the extension is a fast capture surface and the web app is the durable workspace.
Batch Prospecting is where it stops being a toy. You can upload a CSV or paste a list of URLs, run them, multi-select which results to save, and generate outreach and follow-ups in bulk, then export the whole thing to CSV or Excel. For large runs there is a compact batch analysis mode that trades some depth for speed, and there is a resilient fallback path that still produces email content when an AI response fails mid-run, so one bad response does not sink a batch of a hundred.
How it works: the web app and sync
The extension is paired with the web app at signalizeai.org, and the two stay in sync rather than being separate products that happen to share a login. Saved prospects live in a workspace at /prospects with search and filtering, status tracking, inline status editing, and copy, open, and delete actions.
The interesting part is that the extension and the website share the same prospect data and reflect each other live. The extension listens to the site for auth state, sign-out, theme changes, prospect status updates, prospect content refreshes, and install detection. Change a prospect's status on the website and the extension sees it; save from the extension and it appears in the web workspace. To keep that bridge safe, the production manifests only inject the website bridge script on signalizeai.org. Dev manifests additionally allow localhost so I can run the web app locally against the extension without opening that channel up in production.
How it works: auth, storage, and billing
Auth and storage run on Supabase, with Google sign-in. Supabase is also where saved prospects are stored, which is what makes the shared-data model between extension and website straightforward: both talk to the same backend and the same user identity.
The analysis and generation work is served by a Cloudflare Workers backend. Workers is a good fit here because prospecting is bursty and latency-sensitive, and running the request-handling logic on the edge keeps it responsive without me babysitting servers. The extension is configured per environment: a dev build points at a dev API host and localhost, while production points at the live API. Plan limits are enforced on that backend, so the free and paid tiers are a real boundary in the service rather than something the client politely respects.
An honest limitation
SignalizeAI reads what a company chooses to publish. If a website is thin, vague, or mostly a login screen, the research is only as good as that surface. A sparse marketing site produces a sparser prospect record, and the sales-readiness read reflects the signal that is actually there, not private data the company never put online. In practice this means the tool shines on companies with real content and is weakest exactly where a human would also struggle. The batch fallback helps keep a run from failing outright, but a fallback email is a safety net, not a match for a clean generation on a rich site. I would rather be upfront that this is a research accelerator over public information than pretend it manufactures signal that does not exist.
Closing
The version of SignalizeAI users are running today is the result of a lot of unglamorous work: Manifest V3 message passing, a two-way sync bridge that has to be locked to a single origin in production, batch runs that survive individual failures, and plan limits enforced where they cannot be bypassed. The payoff is simple to describe. Open a website, get a prospect record and an email grounded in what that company actually says about itself, and keep the whole thing in a workspace that the extension and the site share.
It is live at https://signalizeai.org, on both the Chrome and Firefox stores, with real users. If you do outbound and are tired of the tab pile, that is exactly who I built it for.
Top comments (1)
The research-and-message-same-pass design choice is the interesting one here. Most lead-gen tooling caches a company profile and generates copy against stale context; doing one pass over the actual pages you're looking at keeps the email honest even if the pages change tomorrow.
For the scraping side of this, what's your split between content scripts and background workers? I drive browsers over CDP for automation work, and the awkward boundary is always the same: the part that needs the logged-in context has to run in-page, while anything that calls external APIs you'd rather keep out of the content script's reach. Curious how you handle that on Firefox, where the permissions model differs enough to matter.