Skip to content
THOMMO.AI
App developmentAI & agentsInternal Platform2026

Thommo Prospecting

An internal business application for finding prospects, reviewing website findings, preparing outreach and keeping track of follow-ups. AI drafts; a person decides what gets sent.

What it shows: Software shaped around a real workflow rather than a generic CRM, with AI only where it helps and a person approving every send.

Next.jsSupabaseGoogle PlacesABRGeminiResend

Internal platform. Sending is live, and every AI-drafted message is still reviewed and approved by a person before it goes

How it came together
  1. Discover
  2. Analyse
  3. Qualify
  4. Draft
  5. Review
  6. Send
  7. Lead
  8. Follow-up
01
The question

If Once-Over can check a site, can it also find the site?

The Once-Over came first: point it at a business website and it tells you, plainly, whether the site is doing its job for AI search and for the people who land on it. I built it originally with tradies and local service businesses in mind, the kind of business that has a website because someone told them they needed one, not because anyone's looked at it since.

Building that raised the more interesting question. Once-Over can tell a business its website has a problem. It can't find the business in the first place. So I started building the other half: a way to actually locate the businesses worth checking, before a person ever manually types a URL in.

That became Thommo Prospecting: find businesses, run them through Once-Over, decide which ones are worth a message, draft that message, and keep track of where each one is up to.

02

Why not just build a CRM

The easy version of this project starts with a CRM and forces a prospecting workflow into it. I did it the other way around: I started with the actual sequence of work, Find, Review, Outreach, Leads, and built the software to match that shape, rather than adapting a generic pipeline tool to fit.

That shows up in small decisions throughout the codebase. Qualification status and lead stage are deliberately separate concepts with their own state machines, because whether a prospect is worth talking to and where a conversation has got to are genuinely different questions. When a lead table I'd built collided in naming with a completely unrelated leads table in thommo.ai's own shared database, I renamed it rather than let two different ideas of "a lead" blur into each other.

  1. Find
  2. Review
  3. Outreach
  4. Leads
The Thommo Prospecting Today dashboard: Find, Review, Outreach and Leads columns showing discovery sources, a prospect queue, outreach drafts and a follow-up, with fictitious example businesses in place of real prospects.
The Today screen, organised as Find, Review, Outreach and Leads. A faithful recreation with fictitious example businesses in place of real prospects.
03

Finding businesses that need help

Discovery combines OpenStreetMap and Overpass for free candidate data, the Australian Business Register for ABN lookups, and Google Places for the businesses that OSM misses, capped and usage-tracked so a discovery run can't quietly run up an API bill. Matching a business to its real website turned out to be the genuinely hard part, not the AI: a three-tier resolution process checks the source data, then Google, then a guess, with a name-overlap check to catch false positives, all logged and live-tuned against real cases where it got it wrong.

04
How it fits together

Once-Over as a component, not a rewrite

Rather than re-implementing any of Once-Over's diagnostic logic, Thommo Prospecting calls the same checker that runs the public tool on this site, over a private, key-authenticated endpoint. One diagnostic engine, two front doors: a person can run it themselves at thommo.ai, or Thommo Prospecting can run it as part of finding who needs it.

It works the other way too. When someone genuinely runs the public Once-Over checker on thommo.ai, that site quietly tells Thommo Prospecting a real visitor just showed inbound intent, a signal the prospecting side treats as more meaningful than a business it found on its own. Neither side depends on the other to be up: if prospecting is offline, the public checker never notices or slows down.

05
Where AI fits

Deterministic first, AI second

Qualification is a plain weighted score, industry fit, geography, independent-business signals, the Once-Over findings themselves, contact availability, not a model's opinion. It's a first-pass formula, not a statistically proven one, and the code says exactly that rather than pretending otherwise.

AI's job is narrower and comes later: drafting the outreach message once a prospect has already qualified. The model only ever sees the prospect record and Once-Over's own pre-approved findings, never invents claims about a business, and every draft is recorded against the model and prompt version that produced it. If the model call fails or the output doesn't validate, a template draft takes over instead of the whole step silently breaking.

Nothing goes out on its own. Every draft sits in a review screen until a person reads it and clicks send.

06
How it operates

A working end-to-end system

This isn't a prototype waiting to be finished. Discovery, website analysis, qualification, drafting, review and sending all run against real data, and outreach itself is live: real messages go to real businesses.

The full loop looks like this: a discovery run finds candidate businesses, Once-Over analyses each one's real website, a deterministic score decides who's worth a message, AI drafts a personalised note from the real findings, I review and approve it, Resend sends it, and a lead is created so the follow-up doesn't get lost.

Qualification and drafting stay deliberately separate the whole way through. The score that decides who's worth talking to is a plain weighted formula, not a model's opinion, and the model's only job is turning an already-qualified prospect and its real findings into a first draft, one a human still reads before it goes anywhere.

07
Where it could go next

The same idea, a bigger boundary

None of what follows is built. But once software is built around the actual shape of a real workflow instead of a generic CRM, the boundary of that system can grow in the same shape it already has, rather than needing a rewrite.

A prospect that turns into a lead could plausibly keep going: into a customer, a quote, a job, a project, an invoice, with the same kind of follow-up discipline the outreach step already has. Job tracking, scheduling, task management, customer communication, document generation, and even invoicing or accounting integrations are all reasonable extensions of the same shape, not a different product.

That's a direction worth keeping in mind, not a roadmap. The same principle that built the first half applies to the second: understand the real operating workflow before reaching for the generic tool built for a different one.

  1. Prospect
  2. Lead
  3. Customer
  4. Quote
  5. Job
  6. Project
  7. Invoice
  8. Follow-up

Build snapshot

Framework
Next.js, TypeScript
Database
Supabase (Postgres), shared project with thommo.ai
Discovery
OpenStreetMap/Overpass, ABR/ABN Lookup, Google Places (New)
Website diagnostic
Once-Over, called via internal API
AI drafting
Gemini, with a deterministic template fallback
Outreach
Resend, live sending, human-approved per message
Leads
Created on send, tracked through to follow-up
Auth
Google OAuth, single-admin allowlist