How this dataset is built

We scrape ~775 homebuilder websites directly. No data aggregators, no licensed feeds, no purchased lists — every field traces back to a specific URL that we can show you, with a timestamp.

We use deterministic parsers (regex, JSON-LD, structured-data extraction) for the ~292 builders whose sites publish in machine-readable formats — DR Horton, Pulte, Lennar, Toll Brothers, the BuilderCloud platform, the NVR (Ryan Homes) platform, Drees, and so on. For the long tail of ~483 smaller builders, we use an AI parser that interprets less structured HTML.

The full collection runs weekly on a fixed schedule. Each run produces a complete snapshot — we are not tracking changes; we are observing the present state. Historical trend lines are reconstructed from those weekly snapshots.

Each community gets a stable internal ID derived from (canonical builder slug, normalized name, city, state). The same physical community produces the same ID across weeks regardless of which scraper saw it.

“Canonical builder slug” collapses sub-brands under their parent: Centex / Del Webb / John Wieland all land under PulteGroup; DR Horton Express / Emerald / Freedom all land under D.R. Horton; Ryan Homes / NV Homes / Heartland all land under NVR. The mapping comes from JBREC's own 60-pair parent-builder seed list documented in the Community Count specification — not invented by us.

“Normalized name” strips lot-width annotations (“Bridgeland 40'” → “Bridgeland”), product collection suffixes (“Easthaven at Bridgeland Central - Horizon Collection” → “Easthaven at Bridgeland Central”), and section/phase labels. Without this, MHI-Coventry alone would appear as 5 communities at Bridgeland when it is actually 1.

Each active community is classified into one of three phases:

• Active— the builder is selling and has inventory data. Selling status comes from the parser; if the feed publishes a status like “Selling”, we use it directly.
• Coming Soon— pre-launch, accepting reservations, OR the parser feed contains no inventory signal yet (conservative classification — we'd rather misclassify a quiet community as Coming Soon than count it as Active without evidence).
• Closeout — final units, fewer than 10% of total lots remaining, OR explicit closeout status from the parser.

A community drops out of the “active” set entirely when (a) the builder marks it sold out, (b) it falls off the weekly scrape for more than 21 days, or (c) an admin manually deactivates it. Reactivation is rare and requires explicit admin action.

These rules align with the 3-value status enum (Active / Coming Soon / Closeout) defined in JBREC's Community Count Documentation.

A master-planned community (MPC) is a multi-builder development with a single master developer who sells parcels to homebuilders. Lakewood Ranch has 10+ builders selling within it; Bridgeland has 15+; Sienna has 12+. The MPC, not the builder, is often the right unit of analysis for our clients.

We maintain a seed list of 0MPCs across the country, compiled from publicly known major master-planned communities (RCLCO's annual best-seller rankings, NAHB award archives, and direct knowledge of major development corridors). Each MPC has a state, metro, master developer, and substring patterns we use to auto-tag communities.

Auto-tagging is conservative. Three guards apply, in order:

• Name match— community name must contain the MPC's pattern as a whole word. “grange” matches “Grange Crossing” but NOT “Granger Pines” (different word).
• State guard— community state must match the MPC's state. A “Reston” subdivision in Texas does NOT tag the Virginia Reston MPC.
• City allowlist— each major MPC has an explicit list of municipalities it spans. A “Bridgeland Estates” in Dallas (same state, wrong metro) does NOT tag the Bridgeland MPC in Cypress. City comparison is normalized to handle parser variants like “Punta-Gorda” vs “Punta Gorda”.

Of 0 active communities, 0 are currently tagged to an MPC; the rest are stand-alone subdivisions or in MPCs not yet seeded.

MPC tags can be reviewed, corrected, or set manually by an admin. Auto-tags are re-derived each week from the current match patterns; manual / reviewed tags are sticky and preserved across runs.

The following records are explicitly filtered out at ingest and never enter the active dataset, because they aren't communities:

• Records whose “name” is actually a street address (DR Horton parser bug — emits per-home addresses as community records). Filtered by digit-prefix detection.
• Records containing JBREC-documented non-project keywords: “spot lot”, “scattered homesite”, “scattered community”, “build on your lot” / “BOYL”, “built to rent”, “mixed-use”.
• HTML attribute fragments (KB Home parser bug — scrapes <img> tag attributes as community names). Filtered by tag/attribute regex.
• Placeholder names: bare “Section”, “Phase”, “Lot”, “Block”, or “Section 10” / “Phase 3” patterns. These are parser artifacts that emit subdivision metadata instead of community names.
• Marketing copy emitted as names: “New Homes”, “For Sale”, “Homes For Sale”.

When a real community happens to contain one of these words (“The Collection at Pine Ridge”, “Lakewood Section Estates”), the filter does NOT fire — pattern anchoring is strict, and unit tests verify the negative cases.

The following are accepted limitations of the v1 dataset. Each has an active improvement track:

• Coming Soon over-count.Communities with no parser-supplied inventory data are conservatively classified as Coming Soon. Some of these are actually actively selling but the builder website doesn't publish lot counts in a machine-readable form. We accept this over-count rather than guess.
• Plan-name pollution.A small number of builders (Kolter, Cates Building, Kindred Homes, Shurm) have parsers that emit floor-plan names as if they were communities. We see these as “Lila” or “The Cambridge” appearing repeatedly. These are flagged for parser fixes.
• Coordinate accuracy. Some builder feeds geocode to the city centroid rather than the subdivision location. The map view is a directional indicator; the address is authoritative.
• Long-tail MPC coverage. Our 70-row MPC seed covers the major multi-builder developments but is incomplete on regional MPCs. The dashboard surfaces the substring matches so analysts can add MPCs as they encounter them.
• MPC city allowlist gaps.Each major MPC has an explicit list of municipalities considered in-scope. We've seeded ~60 of the ~70 MPCs; gaps surface as untagged communities that should be tagged (a known one: an MPC's newer sub-development gets built in a town not yet in the allowlist). The diagnostic sweep that surfaces these is automated; expanding the allowlists is a manual triage decision per metro.
• Lot total source.Some communities lack a total-lot count entirely; we backfill from the most recent observation when available. When the field reads “—”, the builder feed has not published a lot count.

Every weekly run produces a snapshot. The ETL applies the filters described above at ingest. After ingest:

• Communities not seen for more than 21 days are automatically deactivated.
• New communities are checked against the MPC seed and tagged if a pattern matches; admin overrides are preserved.
• The community's first_seen date is preserved across upserts (a database trigger snaps it back if the ETL accidentally overwrites it).
• Empty / partial scrapes are flagged in the run report. A collection that returns zero records with zero errors is treated as a silent failure and surfaces for review.

The goal is systemic quality, not point-perfect accuracy. We'd rather know that 5% of records have known issues and what those issues are, than claim 100% accuracy and have unknown gaps.

On any /mpc/[name] page, each community in the builder roll-up has two inline buttons:

• Confirm (✓)— promotes the tag to “reviewed”. The community stays linked to the MPC and the weekly ETL never re-derives it. Use this when an auto-tag is correct and you want to lock it in.
• Detach (✗)— removes the MPC link. Stored as “detached” sentinel state so the substring matcher can't re-tag it on the next weekly run. Use this when an auto-tag is wrong.

Both actions stamp the signed-in user and timestamp into mpc_match_reviewed_by / mpc_match_reviewed_at for audit.

Not yet built: re-tagging to a different MPC (the dropdown UI). Today, detach + manual SQL re-attach works as a workaround.

Community-level data issues outside of MPC tagging (wrong lots, wrong price, missing amenity, wrong address) are captured via the “Flag issue” button on each /communities/[id] page and queued for triage in /admin/feedback.