The real problem was not too little data
We had spent weeks pulling business records from every public source we could find: trade licences, MSME registrations, business directories, ad-transparency listings. It added up to about a hundred and fifty thousand rows across forty-eight spreadsheets, and every one lived in its own file with its own shape. None of it was connected, so none of it was useful.
The trap was thinking the answer was more data. It was not. Staring at a bigger pile makes the decision harder, not easier. The question we actually needed answered on a Monday was small and human: who are the twenty businesses worth a message this week, and what do we say to each one. Signal Fire is the whole tool built backwards from that one sentence.
A business is an identity, not a row
The first design decision was to stop treating a spreadsheet row as the unit. The same cafe shows up in a trade-licence file, a directory, and an MSME registry under three slightly different names. Those are not three leads. They are one business that three separate sources independently noticed.
So the tool fuzzy-matches every incoming record against the businesses it already knows and folds it into a single identity. And the thing that makes a lead interesting falls straight out of that: how many different sources saw it. One sighting is noise. The same business turning up in three unrelated places at once is a business with something happening. We call that signal density, and named the tiers so a glance is enough.
Why this one, and why now
Density tells you a business is worth attention. It does not tell you what to open the conversation with. A cold message with no reason behind it is just noise from the other side too. So the second half of the tool is about timing: tying each lead to something happening in the real world this week.
Market events land in the tool as they happen: a new food-safety rule, a fuel-price jump, a seasonal spike. Each one is mapped to the kinds of business it actually affects, and carries a plain, usable opening line. A bakery does not just score high in the abstract; it surfaces this week with a specific reason it is worth a message today.That reason is what turns a static ranked list into a live one.
An inbox that only asks when it needs a human
Those events arrive as a messy stream of news and notices, and most of them are irrelevant. Reading every item every week would be its own full-time job, so the design goal here was to spend attention only where judgement is actually needed.
Everything incoming lands in a triage inbox, and the tool sorts it first. A clear single match is flagged ready to confirm. Several possible matches get surfaced for a quick call. A genuinely novel event is marked as needing a real read. Pure background news is bundled for a one-tap bulk skip. In one recent pass this took an inbox of nearly four hundred items down to zero in two sittings, because the operator was only ever deciding the handful in the middle, never wading through the obvious.
The Monday loop, where nothing sends itself
All of it comes together in one weekly routine, and the most important rule in the whole product is the last step: nothing goes out on its own. The tool does the gathering, ranking, and even a first draft. A person decides what actually gets sent.
- Fetch. Pull fresh records and events from every source.
- Brief. Read the week: what is hot, and the reasons why.
- Draft. Write a warm, specific message per top lead.
- Review. A human reads every draft. Nothing is pre-approved.
- Send. Sent by hand, then logged so the loop closes.
Each draft is a starting point a human edits, never a message that leaves without a person reading it. For a tool that touches how you talk to real people, that guardrail is the feature.
Hot is not the same as reachable
Early on we collapsed two different things into one number and it quietly hurt the list. A business can be the hottest lead of the week and still be useless if there is no name to ask for and no way to reach them. So we split the score in two: how interesting a lead is, and whether you can actually act on it, are tracked separately.
That split changed what the tool nudges toward. A hot lead with a gap gets routed to enrichment to fill in the missing owner or phone before it is worth anyone’s time; a merely warm lead you can reach today can still be the better call to make now. And because some of that enrichment costs real money per lookup, no paid call ever fires without an explicit yes. The tool shows the running budget and the price of the batch, and waits.
Making it a place, not a database
For a while the whole thing lived in a raw database file opened in a table viewer. It worked, and it was joyless: every Monday started with remembering which query to run. The tool deserved a front door, so we designed and built one: a small web app with a dashboard, the lead list, the triage inbox, and the controls, each page built around the one thing you come to it to do, a single clear next action per page (the dashboard literally opens with “Start Monday triage”). The point was to make the weekly ritual feel calm and obvious, not like operating machinery.
The result
Signal Fire is a design project that happens to be made of data. The decisions that mattered were not technical: treat a business as one identity rather than many rows, rank by how many sources agree, make timing a first-class reason, spend attention only on the ambiguous, and never let the machine send on its own. It is the tool we actually use to run outreach for the studio, and the habits it runs on are the same ones we bring to designing anything where a person has to trust what the software just did.