Portfolio

---

Built in my role at a B2B company to answer a question the team actually had: who owns which collision-repair shops, where, and which insurer networks accept them. No current source for that existed, so I built one — a Python platform tracking 5,300+ shops across 17 national operators, cross-referenced against insurance Direct Repair Programs (DRPs), that turns a market analysts used to map by hand into a live, queryable dataset flagging acquisitions, rebrands, and closures as they happen.

The U.S. collision-repair industry is consolidating fast. Private-equity-backed operators are rolling up independent shops, large networks acquire and rebrand each other, underperforming locations quietly close, and insurers steer work toward shops inside their Direct Repair Programs. Anyone trying to read this market — a corporate-development team choosing where to acquire, an insurance network manager hunting coverage gaps, a supplier sizing up competitors — needs the same three answers: who owns what, where, and which insurer networks accept it?

Those answers live across 17+ corporate store-locators that each update on their own schedule, in their own format, and go stale the moment a shop changes hands. There was no single current source of truth, just a pile of websites and a lot of manual copying. The decisions riding on this picture — where to buy, build, or compete — are worth millions, and they were being made from lists that were out of date before the spreadsheet was finished.

I reverse-engineered each operator's authoritative data source — XML sitemaps, embedded page JSON, AJAX endpoints, per-state listings — and built 17 scrapers that run in parallel into a single historical database. Because every site is structured differently and several deploy anti-bot defenses, the platform does three things a one-off scraper doesn't:

• It normalizes messy real-world data. Wildly inconsistent address formats — US and Canadian, line-break and route-numbered streets, zip codes with stripped leading zeros — get standardized, so the same shop is never counted twice.
• It tracks change over time. Every shop carries a first-seen and last-seen date, and a fuzzy-matching diff engine catches renames, relocations, and network-tier changes between runs, then infers why a shop disappeared: genuine closure, rebrand, relocation, or migration to a sister brand.
• It protects data integrity. Health checks refuse to record a wave of "closures" when a scrape looks broken, so a website redesign never gets mistaken for shops going out of business.

Where a site reliably blocks automation, I built a clean manual-refresh fallback instead of fighting it — a deliberate choice to keep the data honest rather than brittle.

Tools: Python, Playwright, requests / curl_cffi, rapidfuzz, SQLite, openpyxl.

• A live count of 5,300+ active locations and 690+ tracked closures, with full history on every shop — so an analyst can see which operators are actually adding locations, and read tier and ownership changes as early warning on M&A.
• A cross-network DRP matrix showing which insurer programs accept each location — so an insurer can find metros where its network is thin against rivals and recruit shops to close the gap.
• Closure-reason analysis that separates real closures from rebrands and intra-network migrations — so a shrinking shop count gets read correctly as consolidation, not decline.
• Geographic overlap and state-coverage views — so an acquirer can spot where a competitor is weakest and time an entry before the market converges.

• Replaces days of manual, locator-by-locator gathering per refresh with an unattended run of about five to ten minutes.
• Surfaces acquisitions, rebrands, and closures within a single refresh cycle instead of months later in a trade publication.
• Lets one analyst monitor the entire national landscape — 17 operators, thousands of shops — that would otherwise require ongoing manual tracking shop by shop.

Counts reflect public store-locators, which can lag real-world openings and closings by a refresh cycle; one operator's anti-bot protection blocks automation reliably, so its data refreshes on a weekly manual cadence.