We built a rent comp database this week that updates itself every Monday morning, without anyone touching it again after the first setup. Here’s the exact process:
The idea
Every broker already has a rent comp database. It’s just scattered across old emails, dead OM attachments, and notes from calls nobody wrote down properly. The data exists. It’s just not usable.
So instead of building a new data source, we built a routine that mines the one that already exists. A Claude routine, a scheduled AI agent, checks the inbox, the CRM, and call notes every week, pulls out anything that looks like a rent comp, and logs it into a spreadsheet automatically.
Ask before it builds
Our co-founder Jake dictated the build prompt with Whisper Flow instead of typing it, which is its own small unlock (typing a long prompt takes minutes, talking it out takes twenty seconds), and told Claude one thing explicitly: ask questions before you start building anything.
It asked four. New Google Sheet, or an existing one? What columns should each comp have? Which CRM should it pull from? When should this run, and how far back should the first pull look to seed the database?
We answered: new sheet, a schema Claude proposed itself, Pipedrive, and Monday 7am with a 12-month lookback for the first run. This step matters more than it looks like it does. Skip it and you get a routine built on guesses. Answer four questions up front and you get a routine actually scoped to how the team works.
Where it broke, and the fix
The first run hit a real problem. Claude tried creating its own file, an Excel spreadsheet, then converting that into a Google Sheet and saving it to Drive. The save failed.
The fix was simple once we saw the problem: create a blank Google Sheet first, then hand Claude access to that sheet directly. There’s no direct Sheets API for it to call, so it accessed the sheet through its browser tools instead once it had something real to point at. Skip the DIY file-conversion step entirely. Give it a destination, not a blank slate.
Match the model to the job
We built the whole thing using Fable 5, Claude’s newest model, released the same week we ran this demo. That made sense for the build: reasoning through an ambiguous setup, catching the failed file save, adjusting the schema.
But when we converted the routine into an actual scheduled job, we didn’t keep it on Fable 5, and we didn’t use Opus 4.8 either. We set it to run on Sonnet. A recurring extraction task, running the same steps every week, doesn’t need frontier reasoning on every run. Use the expensive model to solve the problem once. Use the fast, cheap model to run the solved problem forever.
Run it live once before you schedule it
Last piece: we didn’t go straight from “build this” to “run this unattended forever.” We ran it live first, watched what broke, fixed it, and only then converted it into a remote routine, the setting that lets it run without a laptop open or connected to the internet at all. Skip that live test and a broken step just fails silently, every week, until nobody notices the comp sheet stopped growing.
It’s live now. Runs every Monday at 7am. The demo data set is thin because LA multifamily isn’t the team’s own market, but the mechanism doesn’t care whose market it is. The more real deal flow you feed it, the deeper the bench gets. That’s the actual pitch: not a new data source, just a way to stop losing the one you already have.
If you want the exact prompt structure, join the AI for CRE Collective community here.
