Some bugs are obvious right away: an email that won't send, a 500 error. And then there are the ones that hide inside the text itself, invisible until someone reads the sentence out loud. This second category is what this session was about: an empty personalization variable in Lemlist campaigns, and the fix built to replace it, a small n8n sub-workflow that calls an LLM to write... three words of French grammar.
Two sales reps, two different ways of dumping a half-empty contact into our outreach CRM. Here's how we ended up building two n8n workflows to fill that gap, and more importantly, everything that broke along the way: an endpoint that returns an empty CSV instead of JSON, an editing bug that silently duplicated parameters, a rate limit we hit twice, and a "job title in English" that turned out not to be a bug at all.
Each of our sales reps covers several industries, and each industry has a different target audience (IT leadership, marketing, general management) with a pitch that should vary accordingly. Nobody has time to keep up that pace of personalization on top of actual prospecting: here's how an n8n pipeline generates a weekly base of ready-to-edit LinkedIn posts every week, sorted by industry and by target audience; and why the real difficulty wasn't wiring an LLM to a prompt.
At Dolist, the sales team runs its prospecting sequences in Lemlist. Every sequence generates manual tasks (a call, a LinkedIn message, a profile visit) and Lemlist displays them perfectly... in Lemlist. The problem is that nobody lives in Lemlist all day. Here's how a small n8n workflow was enough to land these tasks where attention already is: Teams.
There comes a point where commercial databases are no longer enough.
They can tell you a company exists. They sometimes give you an industry, a size, a website, a LinkedIn account, a few contacts.
But they rarely answer the most interesting question:
Why does this company deserve to be contacted right now?
That question is what gradually led me to work on a broader topic: business signal detection using AI, scraping, automated workflows and some RevOps logic. Not to build a magic machine to sell. Not to replace salespeople. But to better prepare sales work, understand the movements of a company, and turn fairly noisy public data into actionable context.
This page is an entry point. It connects several technical experiments around scraping, competitive monitoring, expansion signals and semi-automated prospecting, and explains the overall reasoning behind these projects.
Some web projects start with a blank page.
This one started with four websites.
Four websites for a single company.
Four entry points.
Four ways of presenting offerings that, in reality, were all part of the same ecosystem.
On one side, there was dolist.com, the main site: the brand, the blog, resources, customer stories, a significant share of the historical SEO equity.
Alongside it:
On paper, each site had its own logic.
In practice, for someone discovering Dolist for the first time, things could quickly get confusing.
The problem I was trying to solve wasn't technical at first. It was a timing problem.
Some projects start because you have a real problem to solve. Not an abstract idea. A concrete problem that comes back every week.
As part of Signar, I needed to answer a simple question: how do you help a sales team monitor its competitors without spending two hours manually searching LinkedIn, Trustpilot, and websites?
It started with a simple problem to solve: SDRs were spending too much time finding companies, identifying contacts, crafting messages, and following up manually.
The real problem wasn't the sales work itself. It was everything that comes before it: the preparation.
This project started in the simplest way possible: avoiding having to open 15 tabs manually just to understand a company's stack.
It's probably the project that taught me the most about real-world scraping, technical signals, the limits of the modern web, and the difference between a script that works and a system that holds up over time.