How I Built an AI Deal-Sourcing Pipeline That Landed a $1.2M Engagement
A senior M&A advisor at a global consulting firm spent the first hour of every morning doing the same thing: reading. Hundreds of merger-market articles a day, scanning for deals where his group could plausibly pitch advisory work. It was high-value judgment work buried under low-value reading work — and the reading was crowding out the judgment.
I built him a system that does the reading in 20 seconds and hands him back a ranked shortlist with a pitch angle already drafted for each deal. It's been in production for over two months. It has surfaced 12+ high-value deals to firm leadership, half of which were picked up, and one of those converted into a $1.2M signed engagement. It's now a widely used tool inside his group.
This is a case study in what tailored enterprise AI actually looks like — not a chatbot bolted onto a workflow, but a system designed around one person's real decision loop.
The Situation
The advisor's edge is judgment: knowing which deals his group is positioned to win, and how to frame the pitch. But that judgment only kicks in after the sourcing — and sourcing was a manual slog across dozens of merger-market and financial news sources every single day.
The volume was the problem. Hundreds of articles daily, most irrelevant, a handful worth acting on. He was the filter, and being the filter is expensive when you're one of the most senior people in the room. By the time he'd read enough to feel confident he hadn't missed anything, the morning was gone.
The Problem in Measurable Terms
The manual scan took one to two hours a day, every day, before any actual advisory thinking happened. Worse, it didn't scale: coverage was capped by how much one person could read, so deals slipped through simply because there weren't enough hours to get to them. There was no memory of what had already been reviewed, no consistent scoring, and no structured record of which deals had been pitched or won. Each morning started from zero.
What I Built
The system is an end-to-end pipeline: scrape → parse → score → surface. Three stages, each designed around a specific constraint.
Scraping with Playwright. The merger-market sources are JavaScript-heavy and don't offer clean feeds, so I used Playwright to render and parse the candidate articles the way a browser would. It pulls and extracts dozens of candidate deal articles in about 20 seconds — the work that used to eat an hour or two. I chose Playwright over a lighter HTTP-and-parse approach specifically because these sources break simple scrapers; the headless-browser overhead was worth the reliability.
Scoring with the Claude API, fanned out asynchronously. This is the core. Rather than feeding articles through a model one at a time, I fan them out through the Claude API as concurrent async requests. Each article gets scored, summarized, and — the part that actually creates value — assigned a specific pitch angle tailored to what this group can win. Not "this is an M&A deal," but "here's why your team is positioned to advise on this one, and here's the angle to lead with."
The async fan-out matters more than it sounds. Deal sourcing is inherently embarrassingly parallel — every article is independent — so processing them concurrently instead of sequentially is the difference between a tool that keeps pace with the morning and one that becomes its own bottleneck. Dozens of articles get their own reasoning pass in the time a sequential loop would still be on the first handful.
Surfacing on a local dashboard. The output lands on a local dashboard rather than an email digest or a spreadsheet. It keeps deal history, tracks the status of each deal through the pitch process, and does ROI analysis on what's been sourced. That persistence layer is what turned a daily scan into an institutional asset — the group now has a memory of what it has seen, pitched, and won, instead of starting cold every morning.
The Results
The headline: in 2+ months of production use, the pipeline sourced 12+ high-value deals to leadership, roughly half were picked up, and one converted into a $1.2M signed engagement. For a tool that took a fraction of the advisor's time to stand up, that's a return that doesn't need embellishing.
Underneath the headline number, the operational shift is just as real. The daily one-to-two-hour scan collapsed to about 20 seconds of machine time plus a few minutes of the advisor reviewing a ranked, pre-summarized shortlist. His time moved from reading to deciding — which is the only part only he can do. And coverage stopped being capped by human reading speed, so deals that would previously have slipped through the cracks now get scored like everything else.
The clearest signal that it worked: it spread. It started as one advisor's tool and is now used across his group. Nobody mandated that. People adopt an internal tool when it earns its place in their morning, and this one did.
What Made This Work
The non-obvious factor wasn't the scraping or the async plumbing — both are solvable engineering problems. It was designing the model's job around the advisor's actual decision, not around the article.
A generic "summarize this deal" tool would have been a nicer way to read the same firehose. What made this land was that the Claude API stage generates a pitch angle specific to this group's positioning. That reframes the output from information to recommendation. The advisor isn't reading summaries and then deciding whether his team should pitch; he's reading a shortlist that already argues why and how. That's the difference between saving someone time and changing what they can do.
The second thing was the persistence and ROI tracking. Enterprise tools live or die on whether they build institutional memory. Deal history and progress tracking meant the system got more useful over time and gave leadership a concrete view of what it was returning — which is exactly what turns a personal script into a group-wide tool with budget behind it.
What Generalized Beyond This Client
The pattern is portable to any role where a senior person spends expensive hours as a manual filter over high-volume information: research analysts scanning literature, BD teams tracking signals, compliance reviewers triaging alerts, recruiters screening inbound. The shape is always the same.
First, gather reliably — use a real browser-grade scraper if the sources fight you, because a pipeline that misses inputs quietly is worse than no pipeline. Second, fan out the reasoning asynchronously — independent items should be processed concurrently through the Claude API; sequential processing is the most common reason these tools feel slow. Third, and most important, design the LLM's output around the decision, not the document — generate the recommendation the expert would have formed, not a summary they still have to interpret. Fourth, persist everything — history, status, and ROI are what convert a clever script into an enterprise asset people trust and adopt.
None of this required fine-tuning, a vector database, or a multi-agent framework. It required understanding one person's decision loop precisely enough to build the system around it. That's usually where enterprise AI succeeds or fails — not in the model, but in how tightly the system is fitted to the real work.
Work With Me
I'm Daisy Huang, a full-stack AI engineer in NYC. I design tailored enterprise AI systems like this one — the kind that fit a specific workflow tightly enough to change what a team can do, not just how fast they read. If your organization has a high-value expert stuck doing low-value filtering, that's exactly the problem I like to solve. Reach out at daisyhuang.dev.
Meta description: Daisy Huang, NYC AI engineer, on the tailored AI deal-sourcing pipeline she built for an M&A advisor — Playwright scraping, async Claude API scoring, and a $1.2M result.