DEV Community

Daniel Mercer
Daniel Mercer

Posted on

Estimating moving costs across 47 states with one pricing model

Most moving quote tools ask for your full address, phone number, and email before they show you a single number. We took the opposite approach: our quote calculator gives a real estimate from just an origin state, a destination state, a home size, and a move month. No address form, no account, no sales call. It runs on 27,854 route pages across 47 states, and it is powered by one pricing model. Here is how we built it.

1. Why we dropped the address form

Every personal-information field on a quote form costs you conversions. People researching moving costs are usually weeks away from booking, and they are not ready to be called by a salesperson. Asking for a street address up front also creates a privacy burden: now you are storing and protecting data you never needed for an estimate.

The product bet was simple. If we could produce a useful estimate without any personal data, more people would use the calculator, and the ones who later requested a formal quote would already trust us. The engineering challenge was making one model accurate enough to cover 27,854 origin-destination routes without knowing the exact addresses.

2. The data foundation: Census migration flows

We started with public US Census county-to-county migration data. It tells us which corridors people actually move along, and volume matters for pricing: heavily traveled corridors have more carrier competition and better backhaul opportunities, which pushes per-mile costs down. Thin, low-volume corridors cost more because trucks often run empty one way.

We aggregate county flows up to state-pair corridors, then normalize volumes into a corridor demand index. That index becomes one input to the model: a high-demand corridor gets a competition discount, a low-demand corridor gets a scarcity premium. Because the data is public and refreshed on a schedule, the model stays grounded in how people really move instead of drifting on stale assumptions.

3. One pricing model: distance bands, weight factors, seasonality

The core of the calculator is deliberately simple, because simple models are explainable, debuggable, and cheap to run. Three components:

Distance bands. Instead of pricing exact mileage, we normalize every route into bands: under 250 miles, 250 to 750, 750 to 1,500, and over 1,500. Banding smooths out the noise in per-mile rates and keeps estimates stable when a route is 812 miles instead of 798. Each band has a base fee and a per-pound rate, calibrated from carrier rate data.

Weight factors. Home size maps to an estimated shipment weight. A studio runs around 1,800 pounds, a two-bedroom around 4,500, a four-bedroom closer to 9,000. Cost scales with weight inside each band, which matches how carriers actually price: the truck space and labor dominate, not the precise mileage.

Seasonality. Moving demand is intensely seasonal. Summer months carry a peak multiplier, winter months a discount, derived from twelve months of search and quote-request data. A June move on the same route can cost 20 to 30 percent more than a January one, and the model says so explicitly instead of hiding it.

The whole thing is a few lookup tables and arithmetic, which means it runs entirely in the browser:

function estimateCost({ band, weightLbs, month }) {
  const { base, perLb } = DISTANCE_BANDS[band];
  const seasonal = SEASONALITY[month] ?? 1.0;
  const corridor = CORRIDOR_INDEX[band.corridor] ?? 1.0;
  return Math.round((base + perLb * weightLbs) * seasonal * corridor);
}
Enter fullscreen mode Exit fullscreen mode

No server round trip, no tracking pixel, no personal data leaving the device. The estimate appears instantly.

4. Show ranges, not false precision

A model like this cannot know about stairs, elevators, packing services, or a piano. Pretending otherwise would be dishonest, so we show ranges instead of exact figures: "$1,150 to $1,480" rather than "$1,312.44". The range width reflects the model's confidence for that band and corridor, wider for thin rural routes, tighter for dense metro corridors. We also list what the estimate includes and excludes right next to the number. Users consistently tell us the honesty of the range is what made them trust the formal quote later.

5. Validation and calibration

We validate the model against real carrier quotes on a rotating sample of routes every quarter. When the median error on a band drifts outside our tolerance, we recalibrate that band's base fee and per-pound rate rather than fudging a global multiplier. Keeping the calibration per band preserves the model's structure and makes each adjustment explainable in a changelog the team actually reads.

What we learned

Dropping the address form did not just improve conversion, it simplified everything downstream: no PII storage, no compliance overhead for the calculator, no spam complaints. And a single transparent model beat a black box for a subtle reason: when a user asks why an estimate changed, we can point at the exact band, weight factor, or seasonal multiplier responsible. That answer is a feature.

The calculator runs on every route page at My Fast Movers, so a visitor can price a move in seconds without handing over a street address. Sometimes the best data strategy is collecting less of it.

Top comments (0)