Our Methodology

Every price on HeatPrice comes from a publicly available dealer listing — a price a heating oil dealer has published for homeowners to see, not a private quote or an estimate. We do not call dealers, negotiate rates, or invent figures to fill gaps. If a dealer has not published a price we can find, that dealer simply does not appear with one.

On a regular schedule, we gather these published prices and organize them into one simple, comparable list. Each becomes a straightforward entry — the dealer, the areas they serve, the fuel type, the price, and the date we gathered it. Prices are collected on a set schedule rather than streamed live, which is a real plus when you're comparing options: right alongside every price you'll see exactly how recent it is, so you're never left guessing whether a number is fresh.

HeatPrice runs on a two-store architecture. The public-facing data — dealers, zip codes, and prices — lives in a SQLite database file that is committed directly into our source code repository and shipped with every deploy. This database is read-only at runtime: no page on the live site writes to it, ever. The only thing that changes the committed database is a fresh round of collected data: the nightly collection is opened as a pull request and lands only after the full build checks and a mechanical data-integrity tripwire pass — a deliberate trade-off that keeps the data current, backed by those automated guards.

Because that database is baked into the build, every price you see was correct as of the moment we last rebuilt the site, not as of the moment you're reading this page. There is no live connection back to a dealer's system, no request-time lookup, and no way for a price to update between builds. This is a deliberate trade-off: a build-time-frozen dataset is slower to reflect a dealer's afternoon price change, but it is also simpler, cheaper to run, and impossible to silently corrupt at request time.

A second, separate database — a managed Postgres store — is reserved in the architecture for data the site itself would need to write while running, such as a dealer claiming their listing or a consumer contact form. That write path is not live today: for now, listing claims and corrections run through the manual review described below, and the only database the live site reads from is the committed, read-only price catalog above. The separation is deliberate by design — if and when a runtime write path ships, it stays entirely separate from the price catalog, so it can never touch the numbers you're comparing.

Not every number we collect from a public listing is a real price. Some listings show a placeholder, a promotional teaser, or a formatting artifact instead of an actual per-gallon rate. Rather than guess at intent, our pipeline applies a simple, mechanical floor-and-ceiling rule: a collected figure must be a positive number of cents per gallon, and it must fall below a fixed sentinel ceiling of $8.00 per gallon. Anything at or above that ceiling is treated as invalid — not as a real, unusually expensive price — because in practice a figure that high is reliably a collection error or a placeholder value, not a genuine quote.

This is a mechanical rule, not a judgment call about what a fair price looks like. We do not exclude a price because it seems too high or too low relative to its neighbors; we only exclude a price that fails this fixed, published bound. That keeps the filtering step auditable and repeatable — anyone with the same raw collected data and the same two numbers (the floor and the ceiling) would throw out exactly the same rows we do.

Every price on the site is honestly labeled with the date it was collected, and every page that shows prices makes clear that the data may be days or weeks out of date. We do not claim real-time pricing anywhere on HeatPrice, and we describe our collection cadence honestly — collection currently runs nightly, and no surface is presented as fresher than it genuinely is.

Because the live site is a frozen build, there is also a build-age signal separate from the data-age signal: even if the underlying data were collected recently, the deployed site only reflects it once a new build ships. The data's age is labeled on every page that shows prices, and we track the build-age operationally — treating a stall in either one as an operational problem to fix, not something to quietly hide from visitors. A build-time guard already refuses to ship a dangerously stale board, and a failed nightly data-refresh run notifies us; a standing, always-on freshness monitor is designed but not yet armed.

HeatPrice does not sell placement, and no dealer can pay to appear more prominently than another. Our price tables default to sorting by each dealer's own publicly-listed price, lowest first, in your browser — re-sortable by name — while the page itself is served in a neutral alphabetical order; our full dealer directory is a neutral alphabetical index. In every case the order depends only on objective, dealer-published details (price, service type, and the dealer's name), never on how much (if anything) a dealer pays us, a dealer's account tier, or any other business relationship. This isn't just a stated policy; it's enforced mechanically. Our own build process scans every database query that produces a dealer list and fails the build if any sorting or filtering logic references a dealer's account tier or billing status. A ranking bug that favored a paying dealer would be caught before it could ship, not after a homeowner noticed something felt off.

The same neutrality extends to how we talk about dealers in guides and glossary entries: we do not describe any specific dealer as the "best" or "cheapest," and we do not use ranking language that implies an endorsement. Where we discuss price differences, we discuss them at the level of the region or the market — the size of the gap between the lowest- and highest-priced dealer serving an area — not as a recommendation of one company over another.

Our database tracks two separate kinds of records that most homeowners never think about as separate: the zip codes we cover, and the dealers who serve them. A single zip code can have several dealers willing to deliver to it, and a single dealer can serve dozens of zip codes across two states — so under the hood, coverage is a many-to-many relationship, not a simple one-dealer-per-area map. When you search a zip code on HeatPrice, we look up every dealer linked to that zip in this join table and show you the prices each of them has published.

Dealer records themselves come from the same public-listing collection process as prices. A dealer is linked to a zip code when our public source lists that dealer as serving the delivery zone that zip belongs to — so coverage is inferred at the regional level from that listing, not separately confirmed for each individual zip. We label it that way on the pages themselves: a dealer's service area is shown as approximate and inferred, not confirmed by the dealer, with a prompt to confirm coverage directly. If a dealer's actual coverage has changed since we last collected it, or if we've made an error, the correction path described below is how that gets fixed, and dealers can also claim their own listing to correct it directly.

The reports on this site — starting with our Rhode Island and Massachusetts heating oil price landscape — are built from the same read-only database that powers every price page, using the same collection and validation rules described above. A report's figures are computed at build time from live queries against that database, not hand-typed or copied from another source, so the numbers you see in a report's table match the numbers you'd see if you queried the underlying data yourself.

Where a report shows a trend over time, that trend is only shown once enough data points exist to support it honestly. With very few snapshot dates in our history so far, a report describes what changed between the two dates we do have — not a smoothed multi-month curve we don't have the data to draw. As more snapshots accumulate, a continuous trend view becomes available automatically, without any change to how the report is built.

Every report is also published with downloadable CSV, JSON, and Markdown copies of the exact same figures shown in its on-page table — generated from one shared calculation so the numbers in the download can never quietly drift from the numbers on the page. Each report carries an open CC BY 4.0 license and a citation block, specifically so it can be re-hosted, quoted, or built on elsewhere with attribution, rather than living only on this site.

If you run a business we list and believe your listing is wrong, out of date, or shouldn't be included, you can ask us to update or remove it. If you spot a figure anywhere on the site — a price, a report number, or a claim in a guide — that looks wrong, we want to know. Every correction request goes through the same review a code change would: someone checks the claim against a primary source before anything changes.