DEEP DIVE · DRAFT · NEVER FINISHED

Supabase Lead Scoring

This one stayed a draft. We already had an insanely over-sophisticated Clay scoring model we were trying to simplify — and Clay is a bad medium for this anyway, because every weight change means going in and editing the table. The idea: mirror accounts into a real database, keep the model simple, and make rescoring cheap when a startup's product and market move underneath you.

draft, never shipped Supabase HubSpot Fibbler Clay (wrong medium) Gong / Linear (speculative)
[ The Problem ]

HubSpot isn't the warehouse. Clay isn't the model.

HubSpot is fine as the shared record for contacts, deals, and ownership. It is a bad place to park every intent, firmographic, and engagement signal you might want to weight later. Custom properties multiply. Workflows get brittle. Joining "engaged with our ads" with "just raised a Series B" and "headcount up 40% in the buying function" turns into a maze of lists and Zaps that nobody trusts as a single priority queue.

Clay was the other trap. We had built an insanely sophisticated scoring model in it — and then spent energy trying to simplify the thing, because maintaining it meant opening tables and editing columns whenever reality shifted. Clay is great at enrichment and enrollment. It is a terrible control panel for a living score. Every rescoring becomes a spreadsheet archaeology project.

The theory: keep HubSpot as the operational CRM, use Clay for the actions (find people, enroll sequences), and put a simple scoring model in a mirrored database you control. Pull signals in. Compute a score. Push back only what sales needs. When the product or ICP moves, you change weights fast — you don't rebuild a Clay cathedral.

What the mirror was for
Account identity + signal history + weights you can change without a RevOps ticket or a Clay table edit. HubSpot stays where reps work. Clay stays the hands. Supabase (or similar) stays the brain.
[ What We Had Instead ]

Channel-specific triggers. Useful. Not holistic.

In practice we ran point solutions: if a signal fired in one tool, we created a HubSpot task. That got people working accounts that raised their hand in that channel. It did not answer "of the thousand accounts we care about, which twenty should we prioritize this week when you look at everything at once."

Fibbler → HubSpot task
When a company engaged with our ads (via Fibbler writing engagement back onto the HubSpot company), a workflow would create a task for the owner. Real signal, real follow-up — one channel, one action, no cross-signal ranking.
[ The Draft Model ]

One ranked queue from every signal that mattered

The unfinished version was supposed to fold those point solutions into a single prioritization layer. Engagement signals (Fibbler ad touches, replies, whatever else you already trust) plus firmographic / change signals (headcount growth, funding rounds, hiring) would land in Supabase against the same account keys we used in HubSpot. A scoring pass would produce a living shortlist: not "who clicked an ad," but "who should the team be working right now, given everything we know."

The firmographic side is why the mirror matters. If you're sizing a TAM — employee thresholds, funding stage, recent raise, industry codes you might exclude — that data already wants to live somewhere you can query and re-cut. Scoring is the same dataset with weights on top, not a separate HubSpot property project every time the ICP drifts.

flowchart TB
  subgraph Signals["Signal sources"]
    FB[Fibbler
ad engagement] FIRM[Firmographic change
headcount, funding, hiring] CRM[HubSpot
lifecycle + ownership] end subgraph Mirror["Scoring mirror · draft"] SB[(Supabase
account + signal history)] WUI[Weight dashboard
sliders, not annual rebuild] SCORE[Weighted score
+ decay over time] RANK[Ranked shortlist
accounts to work] end subgraph Act["Push only the action"] TASK[HubSpot task / Slack] SEQ[Sequence enroll
when score clears threshold] end FB --> SB FIRM --> SB CRM --> SB SB --> SCORE WUI --> SCORE SCORE --> RANK RANK --> TASK RANK --> SEQ style Mirror stroke:#f59e0b style WUI stroke:#f59e0b,stroke-width:2px style RANK stroke:#10b981,stroke-width:2px

swipe sideways on mobile →

[ The Real Bet ]

Weights that move when the product moves

Here's the actual problem with account scoring, especially at a startup: you do it once a year. Twice if you're lucky. Someone builds a model — ours got absurdly sophisticated in Clay — ships it, and then the product changes, the market changes, the persona shifts, and the score keeps ranking accounts like nothing happened. Editing that model means going into every formula and column by hand. That is not how fast companies actually evolve.

If the firmographic and engagement data already lives in a database you control, the interesting interface isn't another CRM property or another Clay enrichment waterfall. It's a simple model with a dashboard where you can adjust the weights as reality changes. Product starts selling harder into revenue operations than marketing? Slide marketing down, slide RevOps up, re-rank the universe. No six-week scoring project. No waiting for the annual ICP refresh. No opening twelve Clay tables to change one assumption.

Example
Persona drifts from marketing leaders toward RevOps. You don't rebuild the model. You open the weight UI, de-weight "marketing title density / marketing headcount growth," bump the RevOps equivalents, and the shortlist reshuffles against the same underlying accounts.
[ Speculative · How Far Could It Go ]

What if the weights adjusted themselves?

I don't know that this is the right solution. I'm just thinking out loud about how you'd take a simple lead scoring model one step further and make it autonomous.

Imagine an AI brain watching the same sources that already tell you what the company is becoming: Gong calls (which personas are showing up, what pain language is converting), product and roadmap signal from Linear (what you're actually shipping and selling into), maybe win/loss notes. It proposes weight changes — or applies them with a human approval step — so the shortlist tracks the business without someone remembering to open the scoring project every quarter.

That's a crazy idea relative to what we drafted. The boring version (a simple model + sliders) was already unfinished. The autonomous version is the north star that made the boring version feel worth designing: not a smarter Clay table, a scoring layer that can notice the market moved before you schedule a workshop about it.

What never got built
Escaping the overbuilt Clay scoring model into a simple Supabase mirror; the firmographic feeds; the weight dashboard; anything resembling Gong/Linear-informed autonomous reweighting. Designed on paper. Never wired end to end.
"Clay is a bad place to keep a living score — you end up editing the cathedral. Startups need a simple model you can move, and maybe eventually one that moves itself when Gong and the roadmap say the persona changed."

Want systems like these at your org?

Contact Me 727-637-2778