The number you actually need isn't a retail price
A gallon of paint has a price at the store today. A finished job doesn't run on that number, it runs on the unit cost: what it takes, in labor, material, and equipment, to install one finished unit of the work. Per square foot of drywall hung, per square of shingle laid, per fixture installed.
Retail price is one input to the material half of one unit cost. It is not the number an estimate is actually built from.
Why retail scraping only fits one kind of contractor
Scraping a home-improvement retailer for pricing makes sense for a residential remodeler who genuinely buys materials at that store. For that segment, retail price and material cost are close to the same thing.
It stops being the relevant number the moment the work is commercial, or the trade buys through distribution instead of retail: electrical, mechanical, roofing. A roofer isn't pricing a job off a home-improvement website, and neither is an electrical contractor buying gear through a supply house.
"Works for every trade" and "scrape a retailer's prices" pull in different directions. We picked the first one, which meant not building the second.
The legitimate version of location-based pricing
If a product needs pricing data that spans every trade and adjusts for where the job is, the real version of that is a licensed, location-factored unit-cost database: the kind estimators already use and trust, with tens of thousands of line items across trades and cost factors for hundreds of North American locations.
That is a normal, well-established way to source estimating data. It is also not where we started.
The case for not buying any of it
There's a stronger case underneath all of this: a contractor's own historical pricing is more accurate for them than any national average. A regional cost database can't know that a particular crew runs faster on repaint turns, or that a contractor has a standing discount from their supplier. Only that contractor's own numbers know that.
Which means outside pricing data is really only needed for one narrow job: getting a new contractor through their first few estimates, before the system has anything of theirs to learn from.
What that means in practice
So the order of operations we built around is: let a contractor bring in their own past estimates first, their real prices, on day one, at no data cost, before ever reaching for a purchased database. A licensed unit-cost database is worth having as a fallback for the line items a new contractor hasn't priced yet, clearly labeled as a regional average rather than their number. Retail catalog data stays out of it unless a product narrows specifically to residential remodel.
That's the same reason BidPilot's estimator learns from a contractor's corrections and past jobs instead of starting from someone else's price list: the best pricing data for a job is the pricing that already worked for the person doing it.