BlogBuild notes7 min read

The prospect list never leaves the machine

ColdDeck runs locally and stores everything in a database on your own disk. That decision cost us a SaaS business model and bought something we would not trade.

ColdDeck runs on your machine. The prospect database is a file on your disk. The crawler runs from your IP, the drafts sit in local storage, and the email goes out through your own Gmail account.

There is no server holding anyone's list. That was a decision, it cost us the obvious business model, and it is the one design choice in the whole system we have never reconsidered.

A hosted version would be worth more money and would require us to hold every user's prospect list on our infrastructure. Those two facts are the same fact.

What a hosted version would mean

The SaaS shape is better commercially in every respect — recurring revenue, easier onboarding, centralised updates, usage analytics. We would also, necessarily, be holding:

  • Every customer's prospect list, which is their commercial pipeline
  • The crawl results for tens of thousands of small businesses that never asked to be assessed
  • Draft emails written on behalf of our customers, before they were approved
  • The reply data, which is a fairly complete picture of who is selling what to whom

That is a genuinely sensitive aggregation, held by a small firm, as a side effect of a convenience. And it is a target — the value of that database to somebody else is considerably higher than its value to us.

Running locally does not mitigate that risk. It removes the category.

The two things it makes structurally impossible

The argument that mattered more than privacy-as-a-feature.

We cannot see your pipeline. Not "we promise not to look" or "we only access it for support". There is no copy on our side to look at. A promise is a policy that can change with a new privacy policy and a two-week notice email; an absent database cannot.

We cannot be compelled to hand it over. Nothing to subpoena, nothing to disclose in an acquisition, nothing in a breach notification. This is the part people underrate — the risk to a customer's list is not primarily that we would misuse it. It is that we might be acquired, or breached, or handed a legal demand, none of which are things our current intentions protect against.

For a tool whose users are frequently one-person consultancies whose prospect list is the business, that distinction is the product.

What it cost

Honest accounting, because local-first is usually presented as a free virtue.

Onboarding is harder. Installing something beats clicking sign-up for approximately nobody. We lose people at that step, and there is no clever fix — it is a real conversion cost.

No centralised updates. Users run whatever version they installed. Bugs persist on machines we cannot reach.

Support is blind. "It's not working" cannot be answered by opening their account. Diagnosis depends on what the user can tell us and what the local logs say, which makes error messages far more important than they would otherwise be.

No aggregate learning. A hosted version would see which detected signals actually correlate with replies across thousands of campaigns. That would make the rule pack genuinely better, and we cannot do it. This is the loss that stings.

No recurring revenue. The business model is worse. That is the trade.

What it made easier

Less obvious, and it partly offsets the above.

The crawl comes from the user's own IP, at their own pace. A hosted service crawling on behalf of five hundred customers concentrates all of that traffic into one place, and the polite-crawler design we care about becomes much harder to hold — you are one shared IP away from looking exactly like the thing you were trying not to be.

Email sends from the user's own mailbox, which is the whole deliverability argument. A hosted sender would need its own domains and warm-up infrastructure, and would be structurally in the business of consuming sending reputation.

No multi-tenancy. The entire class of bugs where one customer sees another's data — including the retrieval version — does not exist. There is one tenant per installation and the operating system enforces it.

No compliance surface. No processor agreements, no data residency questions, no retention policy to write and honour. For a firm of five, that is a meaningful amount of work not done.

When this is the wrong choice

Not a general recommendation. Local-first fits a narrow shape:

  • The data is sensitive and belongs to one user, not shared across a team
  • There is no genuine need for collaboration or a shared view
  • Users are technical enough to install something
  • The value does not depend on network effects or aggregate data

Break any of those and hosted is correct. A tool a sales team of twelve shares needs a server. A product whose quality improves with pooled data needs the pool. Most software is in that category, which is why most software is hosted.

The question worth asking of any tool holding sensitive data is not "how well do they secure it" but "why do they have it at all". Sometimes the answer is a real product requirement. Often it is that hosting was the default and nobody priced the alternative.


ColdDeck is ours, and it is also our own outbound engine. More in why our crawler is deliberately slow, a rule pack, not a model, and the case studies.

Something here

the audit is the cheapest way to find out for certain.