From Five Lead Silos to One Lead Hub: Before and After

When I audited my own sites, the honest answer to “who has contacted my business?” was: I don’t know. Leads were spread across an email inbox, three SaaS dashboards, a PocketBase database, a CSV file and Cloudflare KV. Each site had grown its own way of capturing people, and none of them talked to each other.

This post compares that starting point with the setup I run now, including the part that surprised me most: the PocketBase database I removed from the loop because the app only ever wrote to it.

Before: five mechanisms for five sites

Five mechanisms, two different contact addresses, three privacy policies in three different states, and analytics code for a tool I had already dropped. Most of it wasn’t wrong in isolation. Together it meant:

• No single list. Answering a deletion request meant remembering five places.
• No consistent consent. One site bundled marketing into a required checkbox; another recorded consent: YES for everyone regardless.
• Retention by hope. Nothing expired anything, except where I’d set it by hand.
• Vendors in the critical path. If a survey account lapsed, the main call-to-action on the consulting site would stop working.

After: one lead hub

6 sites ── form POST (same-origin /api/forms/*) ──► one Cloudflare Worker
webaudit backend ── server-to-server (keyed) ─────►   ├─ Workers KV: the record of truth
Cal.com ── signed webhook ────────────────────────►   ├─ phone alert (email domain only)
Mailjet ── bounce/complaint webhook ──────────────►   ├─ double opt-in emails (Mailjet)
                                                      └─ do-not-send list (hashes)
homelab (pull-only) ── every 15 min ── SQLite copy · daily backups · drips · weekly digest

Every site posts to the same Worker on its own domain (so no CORS and no third-party script), and every lead lands in one KV namespace with a key like <site>:<kind>:<time>:<id>. The details of each piece are in earlier posts: the forms Worker, double opt-in with signed links, the do-not-send list, the homelab mirror, the Cal.com webhook and server-to-server audit leads.

The PocketBase question

Webaudit was the best-engineered site of the lot: rate limits, an SSRF guard, expiring report links, and PocketBase as its lead and audit store. After wiring it to the lead hub, every audit was saved twice — once in PocketBase, once in KV.

So I checked what the app actually read from PocketBase. The answer was nothing. Reports are served from files through time-limited tokens; the frontend never queries the database; the only code that touched PocketBase created records (and, later, a retention job I’d just written to delete them). PocketBase was a write-only copy with its own login, its own retention job, and a blind spot: deleting someone from the lead hub didn’t delete them there.

I turned it off by default rather than deleting the code (PB_ENABLED=false), and the lead hub now receives the audit summary it was missing: overall score, detected platform and the category scores. If I ever build client features — logins, “my past audits”, shareable report pages — PocketBase is one setting away.

Pros and cons, honestly

The trade I made is clear in that table: I gave up convenience (dashboards, no-code edits, survey analytics) for control (one list, real consent, real retention, no vendor scripts). For a one-person business that wants to be able to answer “what do you hold about me?” in one command, that’s the right side to be on. For a team that edits surveys weekly, it might not be.

What I capture now

The complete picture after the migration — every form, what it stores, what happens with consent, how long it’s kept:

Across all of them: sign-ups never confirmed are deleted after 30 days; an unsubscribe leaves only a SHA-256 hash so the address is never emailed again; bounces and spam complaints from the email provider feed that same list; and every alert on my phone shows the email domain, never the person.

Takeaways

• Audit your own capture points before building anything; the problems were in the gaps between tools, not inside any one of them.
• Before keeping a second database “just in case”, check whether anything reads it. A write-only store is a liability with a login.
• Turn things off behind a setting instead of deleting them; the cost of keeping the option is one line.
• The final table is the real deliverable: if you can’t write it for your own business, you don’t know what you hold.