I stopped renting lead‑gen tools and built the whole machine.

Everything I build now runs into the same wall: the tool is 80% of what I need, the last 20% is where the money is, and the vendor will never build it because it's specific to me. So I pay $400 a month to be almost right.

Leadd started as a rule written at the top of the repo, before a single component existed:

That rule does a lot of work. It means no homemade scraper — Outscraper already talks to Google Maps better than I will. No contact database — Prospeo, Findymail and Dropcontact already have one. No email validator — ZeroBounce is $0.004 a check and better than anything I'd write.

What it leaves me is the part nobody sells: deciding what to look for, knowing when to stop, and learning from what came back. That turned out to be roughly 29,000 lines of it.

The stack, and why

Any tool can pull 200 dentists in Madrid. Pull them again next Tuesday and you get the same 200 dentists. Every lead tool I've used quietly hands you the same list forever and lets you feel productive about it.

The provider's own answer is a skip parameter — ask for results 200–400 instead of 0–200. I built on that first. Measured live, it returned 67–80% duplicates. The pagination doesn't hold across calls the way you'd hope.

So I threw it out and made freshness a property of the system instead of the provider. Every search is reduced to a fingerprint of (vertical, location, region, language). That fingerprint goes into a global 90-day lock — global meaning across every plan, not per-plan. If any plan searched "dentists / Alajuela" six weeks ago, no plan searches it again for another six.

The plan then walks a ladder of markets rather than paging deeper into one. Duplicate rate measured live after the change: zero.

When a plan exhausts its entire fresh space, it doesn't fail and it doesn't spin. It sets a 30-day cooldown, closes the run at zero, and reschedules itself past the cooldown. A criterion is never left perpetually "due" — that was a bug I shipped once and it cost me a week of phantom runs.

This is the constraint that made the codebase what it is. It's written into the project rules in one line: every step idempotent; dedupe by placeId; re-running a flow never double-writes.

Sounds obvious. It isn't, and here's the shape of the bug that teaches you. Inngest replays a function from the top on every step boundary — code outside a step.run re-executes each time. So this:

Every stage after that is written to survive being run twice: enrichment returns early if the lead already has an email; scoring returns early if it already has a score unless you explicitly force a re-score; the discovery upsert dedupes on placeId before it writes anything.

A business listing gives you a name, a website and a phone. It rarely gives you an address a human reads. So enrichment is a waterfall: Prospeo → Findymail → Dropcontact. First one that returns an email wins, and the lead records which provider found it.

That last part is the whole point. Storing enrichmentSource means I can ask, months later, which provider actually earns its invoice on my verticals in my countries. That's not a question any of the three will answer for you.

Every adapter in the repo — all twenty-plus of them — follows the same contract, because they were painful in the same ways:

• Keyless-tolerant. No API key configured means a logged no-op, not a crash. I can run the whole pipeline with half the integrations dark. Flip INTEGRATIONS_STRICT=true and missing keys become hard failures instead.
• Exponential backoff on 429 and 5xx, in one shared HTTP layer. Written once, not twenty times, not slightly differently each time.
• Normalised return shapes. Three email-finders with three different response schemas become one shape at the boundary. Nothing downstream knows which vendor it came from.
• Zod at the edge. External JSON is parsed before it's trusted. No any reaches a persisted path.

This is the single most valuable line in the codebase and it's a Set with two strings in it.

Catch-all is the trap. A catch-all domain accepts every address, so it looks like a pass. It's actually unverifiable — you're guessing, and the mailbox may not exist. Send enough of them and your sender reputation degrades quietly over weeks. By the time you notice deliverability dropping, the damage is already priced into your domain.

In the mock week above that gate withheld 272 addresses. Those are 272 sends I'd otherwise have made, and the reason the bounce rate stays under half a percent. The most profitable thing this system does is refuse to send email.

Scoring is the one place an LLM belongs in this pipeline. The model gets the whole picture — name, bio, category, rating, review count, socials, website state, whether the email verified, how many times we've seen this business before — and returns four things: a score, a tier, a whyNow, and an angle.

The last two matter more than the number. whyNow is the reason this business is worth contacting this week. angle is the opening line's actual argument. A score sorts a list; those two write the email.

All model calls go through one file. Never a vendor SDK, always OpenRouter, and the model is picked from a dropdown in the UI. Changing the scoring model is a settings change, not a deployment.

Failure is a design decision

Here's the behaviour I'm proudest of. When the LLM is unavailable — and it has been, mid-run, out of credit, with a 402 — scoring returns null and the pipeline keeps going.

The temptation is to throw. It feels correct: the step failed, fail the run. It's wrong. Enrichment and verification run on different, already-paid-for providers, and they're downstream. Aborting on an LLM outage throws away the paid contact data to protect a number I can backfill for free tomorrow. So the gate ranks, it doesn't park. An unscored lead flows on, and a backfill scores it later.

Qualified leads go to Smartlead, grouped into a campaign named after the query that found them. That's it — I'm not rebuilding an email sender, and warming domains is somebody else's full-time job.

What I did build is everything around the handoff: the offer matrix, the segment taxonomy, and a message studio that composes DMs and emails from templates against the lead's angle and whyNow. The sequencer sends. The engine decides what's worth sending and what it should say.

Stages 01–06 are a pipeline. Plenty of people have built one. Stage 07 is the reason this is a different category of thing.

Every plan carries a rolling quality average — an EWMA over its runs, α = 0.5, so it's responsive to the most recent result rather than anchored to ancient history. Before each run the plan reads that number against a bar of 55 and makes one of two decisions:

The plan corrects its own aim. Nobody logs in on Monday to notice that dentists in Costa Rica have stopped converting — the rolling average notices, and next Tuesday it's running physiotherapists instead.

And because the forecast is computed by the same function the runtime uses, the console can show you the next eight runs before they happen. Not an estimate. The actual picks.

Stage 07 optimises inside a space I defined. It gets better at my verticals in my markets. It will never tell me the vertical is dying, or that a category I've never touched is about to spike.

So the Oracle is a separate spine: sensors → signals → opportunities. Sensors run on a schedule and normalise wildly different sources into one signal shape — Google Trends, GDELT news, Polymarket prediction markets, Reddit, Wikipedia pageviews, CoinGecko, X. Each source carries a trust weight. Signals get a cheap deterministic salience score first — momentum log-scaled, weighted by kind, with a geo-relevance bonus — and only the survivors are worth an LLM call.

Opportunities land in four tiers, at two altitudes: tactical, which writes back into the lead engine, and strategic, which is the "what business should exist" question.

Two things keep it from being an astrology generator. First, every opportunity carries its receipts — the exact signal and topic ids it was built from, plus one deterministic line of what the data actually shows. Nothing gets asserted without a citation you can click.

Second, it learns my taste. I mark calls gold, good, wrong or irrelevant, and those verdicts tune weights along four dimensions — signal kind, tier, altitude, and source. Mark enough Polymarket-derived disruption calls as irrelevant and the Oracle stops leading with them. It's a preference model with a human in the loop, not a feed.

A machine that runs itself still needs a cockpit, and I had a strong opinion about what it should feel like: the Nostromo, not a SaaS dashboard. Phosphor green on black, monospace numerals, scanlines, hairline grids, glowing readouts. Three themes ship — Phosphor CRT (default), Industrial, and Prometheus — all driven by CSS custom properties, so the entire console re-skins from one token block.

This is not decoration. Density is the feature. A dense readout means one glance answers "is anything wrong", and the aesthetic gave me permission to put six numbers where a normal dashboard puts one.

The console covers 26 desktop routes and a separate 10-route mobile build, plus a command palette, a chat terminal wired to the same model layer, push notifications, and a Telegram bot for when I'm not at a desk.

Two loops. The inner loop is the pipeline: discover, persist, enrich, verify, score, route. The outer loop is what makes it a machine — outcomes feed the rolling quality average, which changes what the next run looks for. The Oracle sits outside both, watching the world and writing new seeds into the plan set.

These are engineering outcomes, measured against real providers and a real database — not projections, and not customer metrics. Where a number describes my own operation I've said so.

• Unit cost you can actually see. Every paid call reports its itemised cost into one ledger, so cost-per-contactable-lead is a number the console displays rather than something I reverse-engineer from three invoices at month end.
• Attention only where judgment is needed. The pipeline runs on a schedule and lands qualified leads in a queue. I open the console to decide, not to operate.
• Provider independence. Twenty-plus adapters behind one normalised contract. If Prospeo's hit rate drops on my verticals, I see it in the data — because I store which provider found each email — and swapping the order is a config change.
• The sender reputation stays intact. Refusing to send is a first-class outcome. That single gate is what keeps the whole channel alive for the next campaign.
• Failures are cheap. Durable steps mean an outage costs seconds, not a re-run — and re-runs are what actually burn provider credit.
• It compounds. Every run produces an outcome, every outcome moves a rolling average, every rolling average changes the next run's aim. The system is better in week eight than week one without me editing anything.

Not because of this project. Because of what this project cost to build.

Look at what Leadd actually is: a thin orchestration layer over commodity APIs, plus my specific judgment about who's worth contacting and when to stop looking. The commodity half is rented and interchangeable. The judgment half is 29,000 lines that took three weeks — because the tedious parts, the adapter boilerplate, the schema wiring, the test scaffolding, no longer take the time they used to.

Three shifts stack here, and each one on its own is survivable:

What survives that is not features. It's the two things a vendor structurally cannot sell you:

• Judgment specific to your business. My scoring prompt encodes what a good lead looks like for me. A generic tool has to average across every customer, and the average is worthless to all of them.
• A feedback loop that closes on your own outcomes. A vendor can't run my evolution loop, because they don't get to see which of my replies turned into money. That loop is where the compounding lives, and it only closes inside the operation that owns both ends.

So the disruption isn't "AI writes your outreach." Everyone shipped that. It's that the vertical SaaS layer between the APIs and the operator is getting squeezed to nothing — because the operator can now build the layer themselves in the time it takes to evaluate three vendors, and the version they build knows things the vendor never will.

The obvious counterargument is maintenance: I now own twenty API integrations that will break. That's real, and it's the honest cost. But it's also what the $400/month was buying, and the difference is that when a provider changes its response shape I fix it in an afternoon rather than filing a ticket and waiting for a quarter.

The engine is functional, hardened and feature-complete. The console covers 36 routes. The Oracle spine is live with seven sensors and a working operator-feedback loop. Paid ads reporting reads real account data end to end.

Open work, in the order it matters:

• Webhook authentication. Two inbound webhooks currently have no auth. They need a shared secret rather than a session check, because one of them is called by a third-party dashboard. This is the top of the list and it's the kind of thing an audit finds precisely because you built the audit.
• Write-back on ads. Reporting is read-only today. Budget and state changes are next, then attribution back to the lead engine.
• Composable discovery systems. Chained multi-step pipelines — location → posts → users → enrich → link-crawl — as typed, composable steps rather than one-shot flows.
• Production deployment with real auth. The engine runs locally against real providers; the public deployment is gated behind finishing the auth story properly.