DEV Community

Daniel Mercer
Daniel Mercer

Posted on

From spreadsheet to calculator: how we rebuilt our pricing model in public

For a long time, our moving cost estimates lived in a spreadsheet. It worked, in the sense that it produced numbers, but it was slow, fragile, and impossible for a visitor to use. Rebuilding it as a public quote calculator taught us more about our own pricing than years of using the spreadsheet did.

Why the spreadsheet had to go

A spreadsheet is a private tool pretending to be a product. Every new route meant a new row, every pricing change meant hunting through formulas, and every mistake hid in a cell nobody was looking at. Worse, visitors could not use it at all. They had to email us, wait for a reply, and hope the number was right. That friction cost us users who simply wanted a rough idea of what their move would cost.

The decision to rebuild was not about technology. It was about honesty. A public calculator forces you to state your pricing logic clearly, because users will test it, compare it, and complain when it is wrong. A spreadsheet lets you hide behind complexity. A calculator does not.

What the rebuild forced us to decide

The first forced decision was scope: what does the calculator actually need to know? Our spreadsheet asked for everything, because it could. The calculator asks for much less: origin, destination, home size, and move date. Everything else is estimated from data we already have, like typical weights for a home of that size and typical costs for that route.

That restraint was hard. Every field we removed felt like losing accuracy, but every field we removed also increased completion. A calculator that people finish with a slightly rough number beats a calculator that people abandon halfway through for a precise number they never see.

The second forced decision was transparency. We show the estimate as a range, not a single number, because moving costs genuinely vary, and a single number implies a precision we do not have. We also explain, in plain language, what drives the number: distance, weight, timing, and services. Users trust a range with reasons more than a number without any.

The data problem nobody warns you about

The hardest part of the rebuild was not code. It was data. Our spreadsheet had grown organically, with prices from different years, different sources, and different assumptions mixed together. Rebuilding meant auditing all of it: which prices were current, which were guesses, and which were simply wrong.

We found routes priced from data years out of date, and routes where two sources disagreed wildly. Cleaning that up took longer than building the calculator itself, and it was the most valuable part of the project, because it improved every estimate we produce, not just the ones on the website.

What we learned

Build the public version early, even if it is rough. A calculator that real users test will teach you more in a week than a spreadsheet refined in private for a year. Ask for less information than you think you need. Show ranges, not false precision. And audit your data before you automate it, because automating bad data just produces bad answers faster.

If you are planning a long-distance move and want a rough idea of the cost, you can try the result at My Fast Movers. No address form, no phone number required, just a route, a home size, and a date.

Top comments (0)