Under the hood

What actually runs when you hit Find leads.

Not a keyword alert, and not a thin wrapper around one API call. Every scan walks a multi-stage pipeline that spends the cheap passes first and the expensive ones only on what survives.

CONTROL PLANEWeb appdashboard + inboxAPI + webhooksplannedGatewayauth · tenancyTelemetrystructured run logsPlan + quotaper-account limitsRun intakevalidate · enqueueORCHESTRATIONSchedulertriggered per productRun queuelease-based claimWorker poolretry · backoff×NReclaimerrecovers stale leasesDATA PLANE · ACQUISITION + PROCESSINGRedditLinkedInXCredential poolrotates · self-healsNormalise + dedupone schema · no repeatsDedup indexper productScreeningcheap pass before expensive workINTELLIGENCE CORE · PROPRIETARYsignal extraction · scoring · compositionwhat it returns is documented — how it decides isn'tthe only block above that isn't replaceableScored leads0-100 + reasonSTATELead storescored + explainedRun historyevery scan, separatelyresults stream back liveLEGENDserviceplannedstoreproprietary

Layer by layer

What each layer guarantees. The core is described by what it produces, not by how it works — that part stays ours.

  1. 01

    Client surface

    Today that's the web app. The same engine is being kept behind a clean internal boundary so it can be exposed directly — as an API and webhooks — without rebuilding what sits underneath it.

    • Dashboard + lead inbox
    • REST API and webhooks planned
    • No engine logic in the client
  2. 02

    Gateway

    Account isolation, plan limits and run validation all happen before any work is scheduled. One account's scans can never see, starve or bill another's.

    • Per-account isolation
    • Plan and quota enforcement
    • Runs validated before they cost anything
  3. 03

    Orchestration

    Scans are queued rather than run inline, claimed by workers that can be scaled horizontally, and made safe to retry. A crashed worker resumes rather than losing or duplicating a run.

    • Triggered per product, on demand
    • Resumable, retry-safe runs
    • Scales by adding workers
  4. 04

    Acquisition

    One connector per network, each normalising into a single internal shape. The core never learns which platform a post came from, so adding a network is a connector, not a rewrite.

    • Reddit, LinkedIn and X
    • Swappable connectors
    • One schema downstream
  5. 05

    Intelligence core

    The part we don't document. It decides which posts carry real buying intent, what they score and why, and what a genuinely useful reply would look like. What it produces is visible in the product; how it gets there isn't published.

    • 0-100 intent with a stated reason
    • Self-promo and competitor detection
    • Declines to draft rather than pad
  6. 06

    State

    Dedup memory, scored leads and full run history are held per product. The same post never reaches you twice, and every scan stays separately inspectable instead of collapsing into one feed.

    • Persistent per-product dedup
    • Scored leads with reasons
    • Every run kept separately
On the roadmap

Built to be an API, not just an app

The engine was deliberately kept behind a service boundary rather than wired into the interface. The dashboard is one consumer of it — the same intent scoring and response drafting is intended to be available directly, for teams who want it inside their own CRM, workflow or product.

  • The engine already runs behind a service boundary, not inside the web app
  • Runs are queued, isolated per account, and quota-enforced — the hard parts of a public API
  • Connectors are swappable, so new networks land without touching the core
  • Results are structured — score, reason, platform, thread — not scraped HTML

Want access when it ships?

Leave your email — and what you'd build with it, if you already know.

Prefer email? support@intenthunt.io

Why it's built this way

The constraints that shaped the pipeline — and the failure modes they exist to avoid.

Cheap passes first, expensive passes last

Scoring every result properly would be slow and costly, so the pipeline spends the cheapest possible check first and only pays for a full fetch and deep read on what survives. That ordering is the reason a scan lands in about a minute instead of ten.

Nothing gets posted for you

There is no posting integration, and we never hold your Reddit, LinkedIn or X credentials. Replies are drafted; you open the thread and post in your own account, or you don't. That constraint is deliberate — automated replies get accounts banned and communities poisoned.

Every score carries a reason

A number on its own is unfalsifiable. Each score ships with a one-line justification, so when the model is wrong you can see why it was wrong and stop trusting that pattern, instead of quietly losing faith in the whole list.

The same post never reaches you twice

Dedup happens per product and persists across scans. The failure mode for a tool like this is re-surfacing the same twenty threads every morning until you stop opening it.

Run it on your own product

Add a description and watch the pipeline work. First results land in about a minute.

Start free

No credit card required · see the features