From Manual Research to AI-Scored Parcel Lists Before Every Auction Deadline
A 301-node manual pipeline spanning four disconnected tools was replaced by a single containerized platform that delivers AI-scored parcel lists before every auction deadline. Claude Vision AI scores each parcel 0 to 100 with a buy, review, or skip verdict. The investor opens the dashboard to a ranked list, not a wall of raw data.
At a Glance
A 301-node manual pipeline spanning four disconnected tools was replaced by a single containerized platform that delivers AI-scored parcel lists before every auction deadline. Claude Vision AI scores each parcel 0 to 100 with a buy, review, or skip verdict. The investor opens the dashboard to a ranked list, not a wall of raw data. Adding a county is configuration, not development: six Florida counties run today; the path to all 67 is configuration files, not code.
Challenge
The Problem
An auction date is three days out. Six Florida counties have listings posted. The investor needs to know which parcels are worth bidding on before the opening bid deadline.
In the old system, that research began with Automa, a browser automation tool running scripts against each county property appraiser portal. Each script navigated the county site, logged in where required, and extracted parcel data row by row: parcel ID, assessed value, acreage, land use code, owner history. That data then flowed into n8n, which moved it between systems. Notion held the research notes. Google Sheets tracked which parcels were active, which had been reviewed, and which were flagged for bidding.
Four tools. Three hundred and one nodes connecting them. Every node a potential failure point.
Florida's county property appraiser sites are maintained independently by each county. Layout updates happen without notice. A county redesigns its parcel search table, changes a class name on a data cell, moves a field to a different column. The Automa selector pointing to that element stops resolving. The scrape returns empty records. n8n receives nothing. Notion stays stale. Google Sheets shows auction listings that no longer reflect current data.
The four tools were sequential. Automa fed n8n. n8n fed Notion. Notion fed Sheets. Break the first link and nothing downstream updates. One CSS change on one county portal was enough to stall the entire research workflow for that county until someone noticed, identified the broken selector, and fixed the script.
The fragility problem was compounded by a prioritization problem. Every parcel that cleared the scraping step received the same manual review attention. A waterfront lot likely worth a serious bid went through the same review pass as a landlocked swamp parcel with a $500 opening bid. The four-tool pipeline had no scoring layer. It produced data. The investor did all the filtering. Prioritizing that data was entirely a manual activity applied to every record equally.
Six counties, each with multiple parcels per auction cycle. The review load scaled linearly with the number of counties covered. Adding a seventh county meant adding another Automa script, another n8n flow, more Notion templates, more Sheets columns. Each new county touched every layer of the stack. Four disconnected tools held together by manual effort. Three hundred and one nodes that could break in 301 places.
Solution
The 7-Stage Pipeline
The replacement is a single containerized platform. Five Docker services. Seven pipeline stages running in sequence through BullMQ. One database. One dashboard. No manual data transfer between tools.
auction-monitor
This processor watches each county's auction calendar continuously. When a county publishes a new listing, the monitor writes the event to the database and queues the next stage. The investor does not watch calendars. The system watches them.
scrape-listings
This processor pulls auction details for each queued event: parcel ID, auction date, opening bid, legal description. The structured data lands in the database and the next stage is queued automatically.
scrape-property
This processor takes each parcel ID and hits the county property appraiser portal to retrieve assessment data: land use classification, acreage, owner history, improvement value, site address. County PA sites are structurally inconsistent. Putnam County's parcel table looks nothing like Hernando County's. Okeechobee uses different field labels than Charlotte. Marion requires a login flow that Pasco does not. The processor handles this through configuration, not code branching. Each county has its own config object that defines its login sequence, field mappings, and CSS selector patterns. Adding a new county means writing a config file. It does not mean modifying the processor, adding a new queue, or touching the database schema. This stage runs its Playwright sessions through a VPN sidecar (Gluetun/Surfshark, US Miami exit IP) since the investor accesses the platform from outside the United States.
geo-coordinates + screenshots
The geo processor enriches each parcel record with GPS coordinates. The screenshot worker then captures four images per parcel automatically: Google Maps satellite view of the parcel location, street view from the nearest accessible road, the county parcel map showing boundaries and adjacent parcels, and a FEMA flood zone map for the parcel coordinates. Four images, captured automatically, stored with structured metadata.
flood-check
This processor queries FEMA flood zone classification for each parcel and writes the result to the parcel record. Flood zone status directly affects property value, insurability, and development potential. It belongs in the data before analysis runs, not as an afterthought during manual review.
AI Vision scoring
This stage did not exist in the old system. There was no equivalent. Claude Vision AI receives the four screenshots plus the structured property fields and returns a score from 0 to 100. The model evaluates location quality from satellite imagery, flood exposure from the FEMA map, visible road access, neighborhood character, and what the assessment data indicates about value relative to the opening bid. Alongside the score, the model returns a verdict: buy, review, or skip. Parcels that score below the threshold get a skip verdict and do not surface in the investor's default dashboard view. The AI does the first-pass filtering. The investor's attention goes to the parcels the data says to look at.
Results
Before and After
Before the platform: four tools, 301 nodes, manual data transfer at every layer, no scoring, and fragile browser automation that broke when a county updated its portal. After: one containerized platform, five Docker services, seven pipeline stages, and a scoring system that filters parcel data before any human sees it.
Previously, the research workflow ended with a list of parcels. All of them. Every parcel the scraping stage pulled from a county's auction calendar, regardless of assessed value, flood risk, location quality, or any other factor affecting whether a parcel is worth a bid. A landlocked swamp parcel with a $500 opening bid consumed the same review time as a waterfront lot with a $50,000 opening bid and strong comparables nearby.
Now the pipeline produces a scored, ranked list. Every parcel that completes the seven stages has a 0 to 100 score and a buy, review, or skip verdict before the investor opens the dashboard. The AI Vision analysis, running against four automatically captured images per parcel, surfaces location problems, flood exposure, and access issues before a human minute is spent on that parcel.
The CSS selector fragility is gone. When a county updates its portal, the config for that county gets updated. One file. One county. Everything else keeps running.
Related: Property Research Pipeline →