Lesson 3.1.5
Build a database that keeps itself up to date
What this costs
The design decisions in this lesson are what determine the ongoing bill.
Before you start
Lessons 3.1.1 to 3.1.4.
This is the idea the original Akademy ended on, and it is a real thing you can build rather than a thesis. A living list: new companies arrive on their own, stale facts refresh, contacted people are suppressed, and the whole thing costs a predictable amount per week.
The five parts
- 1
An intake, on a cadence
One or two scheduled builders pointed at the sources that actually change. Everything else is a one off you run when you feel like it.
- 2
A suppression gate, before anything paid
Existing companies, contacted people, excluded accounts, recorded rejections.
- 3
A cheap qualifying layer with hard conditions
Free filters plus one cheap column plus a free score. Nothing expensive runs above this line.
- 4
An expensive layer, gated on the score
Contacts, validation, personalisation. Runs on a small fraction of intake, every cycle.
- 5
An outlet
A push to the CRM or sequencer, and a notification. A list that refreshes into a table nobody opens is not a system, it is a hobby.
Different facts age at different speeds, and treating them the same is what makes refreshes expensive. A company name almost never changes. A domain rarely changes. A person in a role changes every couple of years. A hiring signal is stale in 90 days. Refresh each on its own clock rather than refreshing the row.
Check yourself
0 of 2 answered1.Which number tells you a self refreshing list is designed well?
2.Why refresh different fields on different clocks?
Related and next
This lesson is written and complete. Its screen recording is still to come, and the written walkthrough is designed to stand on its own without one.