DEV Community: Daniel Mercer

Why moving quotes differ by thousands for the same route

Daniel Mercer — Mon, 02 Nov 2026 07:05:47 +0000

Ask three movers to price the same long-distance move and you will often get three numbers thousands apart, which makes customers understandably suspicious. Somebody must be lying, right? Usually, nobody is. The quotes differ because the movers are not actually pricing the same thing, even when the route looks identical.

The first difference is what counts as the move. One quote may cover loading, transport and unloading only, while another includes packing materials, furniture disassembly, and a month of storage that the customer never asked for but also never declined. Comparing headline numbers without comparing inclusions is like comparing the price of a car with the price of a car plus insurance, fuel and servicing.

The second difference is weight versus volume. Long-distance pricing is usually weight-based, but weight is estimated, not measured, until moving day, and estimators disagree honestly about how much a household weighs. A three-bedroom house can plausibly be estimated anywhere from 7,000 to 10,000 pounds, and that range alone explains a large part of the price gap.

The third difference is timing. A mover with a truck already going your way can price sharply, while a mover who must send a truck out empty charges for the empty leg too. Season matters as well: summer quotes run higher because demand runs higher, and a flexible date can be worth real money.

The fourth difference is the estimate type. A non-binding estimate can change on moving day when the actual weight is known, while a binding estimate locks the price but usually starts higher to cover the mover's risk. Neither is dishonest, but they are not comparable numbers, and customers who compare them directly will always feel misled.

The practical advice is simple: ask every mover for the same written breakdown, same inclusions, same estimate type, same date window, and then compare. And before you call anyone, get a rough independent number first: the free calculator at https://myfastmovers.com estimates long-distance moving costs from route data, which gives you a baseline to judge every quote against. If a quote lands far from that baseline, you now know which questions to ask, and that is worth more than any single number.

How we serve 56,000 game pages from a single static build

Daniel Mercer — Mon, 02 Nov 2026 07:04:14 +0000

When people hear that GameZiko lists more than 56,000 browser games, they usually picture a huge database, a fleet of servers, and a team keeping it all running. The reality is much simpler, and deliberately so: the whole catalogue is served from a single static build. No database queries at request time, no per-page server rendering, just files on a CDN. Here is why that choice works, and where it bites.

The first reason is speed under load. A game page is mostly the same for every visitor: the title, the description, the embed, and the surrounding navigation. Generating that page fresh for each visitor would burn server time on work that never changes, while a prebuilt file is served in milliseconds by a CDN edge node near the visitor. When a game suddenly gets popular, nothing has to scale, because the file was already there.

The second reason is cost. A static build means the hosting bill stays flat no matter how many pages exist, because storage is cheap and bandwidth is the only variable. A database-backed catalogue, by contrast, grows more expensive with every page and every query, and the bill arrives whether or not the traffic does. For a free site with no sign-ups and no paywall, keeping the bill boring is a survival strategy, not a preference.

The third reason is reliability. There is no database to go down, no connection pool to exhaust, and no query that gets slower as the catalogue grows. If the build succeeds, the site works, and if a deploy goes wrong, the previous build is still there to roll back to. That simplicity is worth more than any feature a dynamic stack would add.

The trade-offs are real, though. Every change, even a typo fix on one page, means rebuilding the whole catalogue, which takes time and discipline. Search and filtering have to happen in the browser or through a prebuilt index, not through a database query, and anything genuinely personal, like saved favourites, has to live in the visitor's own browser, not on our servers.

The lesson we keep relearning is that boring infrastructure is a feature. A single static build will never be the most exciting architecture, but it serves 56,000 pages quickly, cheaply and reliably, and for a free games portal, that is the whole job. You can play the games themselves at https://gameziko.com, no download and no sign-up needed, which is exactly how a static site should feel: instant, and invisible.

How we handle quote requests for routes we have never priced

Daniel Mercer — Sun, 01 Nov 2026 07:26:41 +0000

My Fast Movers publishes cost estimates for 27,854 long-distance moving routes. That number sounds comprehensive until a user types in a route we have not published, and then the honest answer is that we do not have a specific number for that pair of places. How we handle that moment matters more than the size of the catalogue.

The first rule is never to invent a precise-looking number. A quote calculator that returns a confident figure for a route it has never priced is lying with formatting, and users can feel it when the real quotes arrive wildly different. So for an unpriced route, we show a range built from the nearest comparable routes: similar distance, similar region, similar home size, with the comparison explained in plain language next to the number.

The second rule is to say what the range is made of. A range without an explanation is just a vaguer lie, so the page shows the distance band, the home-size assumptions and the factors that move a real quote up or down: stairs, long carries, packing help and timing. A user who understands why the range is wide trusts it more than a user handed a single number with no workings.

Under the hood, the fallback is a distance-and-size model, not a lookup. We take the mileage, apply the per-mile cost curve fitted from our priced routes, adjust for home size, and widen the band as the route gets further from anything we have actually priced. The further the extrapolation, the wider the band and the clearer the warning. Precision that is not earned is worse than a wide range that is honest.

We also log every unpriced-route request, anonymised, and those logs decide what gets priced next. A route requested fifty times in a month jumps the queue for proper pricing, because demand is the best evidence of what the catalogue is missing. The catalogue grows in the direction users actually travel, not the direction we guessed.

The lesson generalises beyond moving. Any estimator, pricing tool or calculator will meet inputs it was not built for, and the choice is always the same: fake precision, or an honest range with its workings shown. We chose the range, and our users have rewarded us for it.

You can try the calculator yourself at My Fast Movers, where long-distance moving costs are estimated without an address form: https://myfastmovers.com

Why our game pages have no login wall, and what that costs us in analytics

Daniel Mercer — Sun, 01 Nov 2026 07:25:23 +0000

Every game page on GameZiko loads the same way: open the link, play the game. There is no account, no sign-up form, no "continue with Google" button standing between a player and a game. That was a deliberate choice, and it is one we revisit every time someone asks why our analytics look so thin.

The obvious benefit is conversion, if you can call it that. A player who clicks a game link and hits a login wall bounces. A player who clicks and is playing within two seconds stays. For a catalogue of 56,000 browser games, most of which are discovered through a search result or a shared link, removing friction matters more than collecting email addresses we would never use well.

The cost is real, though. Without accounts, we cannot tell a returning player from a new one with any confidence. We cannot build a "your recently played games" list that survives a cleared cache, and we cannot send a "come back" email to someone who drifted away. Our analytics are aggregate shapes, not user journeys: which categories get played, which games hold attention, which pages load slowly. That is enough to run the site, but it is not enough to run a growth team, and we have made peace with that.

There are technical upsides that people forget. No login wall means no session handling on game pages, no authentication round trip before the game embed loads, and no personal data to protect on those pages. Our game pages stay light, which is part of why they work on old phones and slow connections. The page is a game, a description and a handful of links, and nothing else needs to happen before play starts.

We do track what we can without identifying anyone: which games are started, which are finished, and where players drop off. That tells us more about game quality than a user profile would. A game that everyone abandons in thirty seconds has a problem, whatever its category, and a game that players return to three days later is doing something right, even if we never learn who those players are.

Would a login wall earn us more? Probably, in the narrow sense of owning an audience we could email. But it would cost us the thing players actually value about the site: that it just works, instantly, with nothing asked in return. For a free games portal, that trade is not worth making.

If you want to see the result, GameZiko has thousands of free browser games that open and play instantly, with no download and no sign-up: https://gameziko.com

How we test quote accuracy without real customer moves

Daniel Mercer — Sat, 31 Oct 2026 07:04:24 +0000

A moving cost calculator has a testing problem. You cannot run a real move every time you change the pricing logic, and you cannot ask real customers to be your test cases. So we test quote accuracy without real moves, using a set of invented moves that cover the cases real moves actually produce.

First, we build a library of test moves. A studio flat moving one state over. A four-bedroom house moving cross-country. A move with stairs at both ends, a move with a long carry from the truck to the door, a move with a piano, and a move with nothing unusual at all. Each test move has an expected price range, agreed in advance, so a change that moves a quote outside that range fails loudly instead of slipping through.

Second, we test the edges, not just the averages. The average move is easy to price. The moves that break calculators are the odd ones: a very short move that still needs a full crew, a very long move with a small load, a move in the cheapest month versus the most expensive month. If the calculator handles the edges sensibly, the middle takes care of itself.

Third, we test what the form does not ask. Our calculator deliberately does not ask for an address, so it must estimate from distance, home size and a few honest inputs. That means testing what happens when a visitor leaves a field blank, picks an unusual combination, or changes one answer halfway through. A calculator that breaks on an unusual answer is worse than a calculator that admits uncertainty.

Fourth, we compare quotes over time. Every time we change the pricing model, we run the same test moves through the old and new versions and look at the difference. A change that moves most quotes by a small amount is probably fine. A change that moves a few quotes by a huge amount needs an explanation before it ships.

What still breaks? Real moves are messier than test moves. A customer always has one more item, one more flight of stairs, or one more constraint that no test case captured. So we treat test moves as a safety net, not a guarantee, and we watch real quote patterns for surprises the tests missed.

The lesson is simple: you do not need real customers to test a calculator, but you do need realistic cases, honest expected ranges, and a comparison step before every release. If you build a pricing tool, build its test moves first. They are the cheapest moves you will ever run.

You can see the result at My Fast Movers, a long-distance moving cost calculator that works without an address form: https://myfastmovers.com

How we keep game thumbnails fast when a page lists hundreds of games

Daniel Mercer — Sat, 31 Oct 2026 07:03:03 +0000

A game portal page that lists hundreds of games has a thumbnail problem. Each thumbnail is small, but hundreds of small images add up to a page that feels heavy, especially on a phone or a slow connection. The fix is not one trick. It is a set of small decisions that keep the page light even when the catalogue behind it is huge.

First, we never load all the thumbnails at once. Only the images near the top of the page load immediately. The rest wait until the visitor scrolls near them. This is lazy loading, and it is the single biggest win, because most visitors never scroll through an entire list of hundreds of games. Loading images for games nobody sees is pure waste.

Second, we keep thumbnails small on purpose. A thumbnail displayed at a few hundred pixels wide does not need a full-size image. We serve a version sized for the display, in a modern format where the browser supports it, and we let older browsers fall back gracefully. A thumbnail that is a tenth of the size loads a tenth as fast, and nobody can tell the difference at that size.

Third, we reserve the space before the image arrives. Without a reserved size, each image pushes the page around as it loads, and the layout jumps under the visitor's finger. Setting the width and height in advance keeps the grid stable, so a visitor can tap a game without the page shifting at the last second.

Fourth, we treat the thumbnail as a promise, not a decoration. A blurry or misleading thumbnail makes a visitor bounce, and a bounce costs more than a slow load. So we pick thumbnails that show the actual game, not a generic splash screen, and we keep them consistent in size and style so the grid is easy to scan.

What still breaks? Caching, as always. A game that changes its artwork can keep showing the old thumbnail until the cache catches up, so changed images get a new path rather than overwriting the old one. And a page with hundreds of games still needs a sensible limit: we paginate long lists, because no visitor benefits from a page that never ends.

None of this is glamorous. Lazy loading, right-sized images, stable layouts and honest thumbnails will carry a huge catalogue further than any clever image pipeline. If you run a content-heavy site, start with the boring choices. They are boring because they work.

You can see the result at GameZiko, a free browser games portal with 56,000+ HTML5 games, no downloads and no sign-ups: https://gameziko.com

What moving quote forms get wrong about stairs, elevators and long carries

Daniel Mercer — Fri, 30 Oct 2026 07:07:41 +0000

Most moving quote forms ask two questions: how big is your home, and how far are you moving? Those matter, but they miss the details that decide whether moving day takes four hours or eight. Stairs, elevators, long carries and tight doorways are where estimates go wrong, and they are exactly the details a good form should ask about before anyone talks price.

Start with stairs. A third-floor walk-up is a different job from a ground-floor flat with the same number of rooms. Every flight adds carries, rest breaks and risk, especially for mattresses, wardrobes and appliances. A form that asks only for bedroom count treats both jobs as identical, and the crew finds out the truth on arrival. Asking "how many flights of stairs, at each end?" is a small question that prevents a large surprise.

Elevators are subtler. An elevator helps, but only if it is reserved, large enough and available for the whole job. A small passenger lift that fits one wardrobe at a time is barely faster than stairs, and a building that requires the lift to be booked in a two-hour window creates a hard deadline for the whole move. A good form asks whether there is an elevator, whether it needs booking, and whether it fits large furniture. "Yes, there is a lift" is not enough information.

Then there is the long carry: the distance from the truck to the front door. A home with a long driveway, a gated complex or a loading bay far from the entrance adds dozens of trips, each one carrying weight across open ground. In bad weather or summer heat, that distance also decides how fast a crew can safely work. Forms rarely ask about it, and customers rarely think to mention it, because the distance feels normal to them. It is only normal until you carry a sofa across it twenty times.

Doorways, turns and parking matter in the same way. A sofa that fits through a door with an inch to spare is fine; a sofa that needs a door removed from its hinges is a different job. Street parking versus a loading dock decides how far the truck can get, which feeds straight back into the long carry. None of these are exotic situations. They are ordinary homes, and ordinary homes are where estimates fail.

So why do forms skip them? Because every extra question costs completions. A form with twenty fields converts worse than a form with five, and product teams know it. The answer is not to ask everything up front, but to ask the high-impact questions in plain language and to explain why each one matters. "How many flights of stairs?" with a one-line note saying stairs change the time estimate will get honest answers. A bare dropdown labelled "Access" will not.

Our approach on My Fast Movers is to estimate from route and home size first, keep personal details out of the calculator, and treat access as a clearly labelled adjustment rather than a surprise fee discovered on moving day. The estimate is honest about what it includes and what can change it, and that honesty matters more than false precision. A quote that says "about this much, and here is what would change it" is more useful than a quote that pretends to know to the dollar.

If you build quote or booking forms, audit them for the access questions. Stairs, elevator booking, carry distance, parking and the largest awkward item are five questions that will improve your estimates more than any redesign of the price display. Your customers already know the answers. The form just has to ask.

My Fast Movers is a long-distance moving cost calculator and route directory, with a free estimate tool that works without an address form.

Serving 56,000 game pages without a database meltdown: the boring caching choices that work

Daniel Mercer — Fri, 30 Oct 2026 07:06:04 +0000

Running a browser games portal with more than 56,000 game pages teaches you one lesson fast: the interesting engineering is not the game itself, it is everything around it. A game page is small. Fifty-six thousand of them, requested in unpredictable spikes whenever a game gets shared, is a different problem. The choices that kept our site stable are boring, and that is exactly why they work.

First, treat game pages as static content. A game listing does not change every minute. Its title, description and category are stable, and the game file itself changes rarely. So we serve pages that are built ahead of time rather than assembled from a database on every request. The database still exists, but it is not in the hot path for a normal page view. When a page does not need fresh data, do not ask the database for it. That single decision removes the most common failure mode for a content-heavy site: a traffic spike turning into a database queue.

Second, load the game only when the visitor asks for it. A game file can be far larger than the page around it, and loading it eagerly for every visitor wastes bandwidth and slows the first paint. Our pages load the light shell first: title, description, thumbnail and controls. The game itself starts when the visitor presses play. Visitors who are just browsing never pay the cost of a game they never play, and visitors who do play get a page that already feels fast.

Third, cache aggressively and invalidate deliberately. Static pages, thumbnails and game files all carry long cache lifetimes, served through a CDN so repeat visits and nearby visitors do not all hit the origin. The trade-off is staleness: when a game file or description changes, the old version can linger. We handle that by versioning changed assets rather than clearing the whole cache. A new game file gets a new path, so old pages keep working and new pages pick up the new file immediately. Blanket cache purges are a last resort, not a routine.

Fourth, keep the page itself light. This is the least glamorous work and the most valuable. Every script, tracker and widget on a game page competes with the game for the visitor's device, and many of our visitors play on modest hardware or phones. We keep our own page code small, defer anything that is not needed for the first view, and test pages on a low-end device, not just a fast developer machine. A page that feels instant on a flagship phone and sluggish on a three-year-old phone is not a fast page.

Fifth, skip accounts where accounts add nothing. Our games need no sign-up and no download, and that is a product choice as much as a technical one. No login system means no session database, no password resets and no account-related failure modes on the critical path. Visitors play immediately, and the site has fewer moving parts to break. Accounts make sense for saved progress and social features, but they are not free, and a portal that does not need them should not pay for them.

What still breaks? Cache invalidation, as always. A changed game that keeps serving the old file is the bug we watch for most, and it is usually a versioning mistake, not a traffic problem. The other recurring issue is a single popular game swamping one cache node, which is a reminder that even a good cache needs monitoring. We watch for sudden spikes per game, not just total traffic, because one viral game behaves very differently from steady growth across the catalogue.

None of this is novel, and that is the point. Static pages, lazy loading, long caches with versioned assets, light pages and fewer moving parts will carry a large catalogue further than any clever real-time architecture. If you run a content-heavy site, start with the boring choices. They are boring because they have already survived everyone else's traffic spikes, including ours.

You can see the result at GameZiko, a free browser games portal with 56,000+ HTML5 games, no downloads and no sign-ups.

What 27,854 moving routes taught us about American migration

Daniel Mercer — Thu, 29 Oct 2026 07:32:19 +0000

What 27,854 moving routes taught us about American migration

There is a particular kind of knowledge you only get from looking at a very large map for a very long time. Not statistics, not a report with neat percentages, but a feel for the shape of things: which routes people ask about again and again, which moves surprise you, and how the questions people ask change depending on where they are starting from.

Our site publishes a moving cost calculator with route pages covering thousands of city pairs across the United States. Spend enough time maintaining those pages, answering the questions that come in around them, and a picture of American migration starts to form. Not from any single route, but from the pattern of all of them together.

People move toward jobs, but they ask about weather first

The questions people ask before a move are rarely the questions you would expect. Job markets and housing costs are the real drivers, everyone knows that, but the questions that arrive first are usually about the practical texture of a place: what the winters are like, how far the good schools are, whether a neighbourhood is walkable, what the commute actually feels like at rush hour.

This tells you something important about how moves really happen. The decision is made on spreadsheets and salary offers. The anxiety is about daily life. A move is not just a change of address, it is a change of every small routine at once, from the grocery store to the morning light. People researching a route are really rehearsing that new life in their heads, one question at a time.

Long moves are planned; short moves are improvised

One of the clearest patterns across thousands of routes is the difference between a cross country move and a move two states over. Long distance moves generate careful, early research. People compare quotes months ahead, read about timing, and worry about the logistics in detail. Shorter interstate moves are often researched in a rush, sometimes days before the move itself, with a very different tone: less planning, more urgency, more "can this just be done by the weekend?"

Neither approach is wrong, but they need different help. The long planner wants a thorough breakdown and time to compare. The rushed mover wants a clear answer fast: what will this cost, who can do it, and what do I need to have ready. A calculator that serves both has to give the quick number first and the detail second, not the other way around.

The routes that surprise you

Every migration map has its famous corridors, the ones everyone expects. But the long tail of routes is where the interesting stories live. People move between city pairs you would never predict, for reasons that are entirely personal: to be near a parent, to follow a partner, to return to a hometown after years away, to start over somewhere nobody knows them.

These moves are often the most stressful, precisely because they are unusual. There is less advice available and fewer friends who have done the same move. Good route information matters most exactly here, where the generic advice runs out.

What people consistently underestimate

Across thousands of routes, the same underestimates recur. People underestimate how long packing takes, often by days rather than hours. They underestimate the value of labelling boxes properly, and rediscover this at midnight in a new home surrounded by identical cardboard. They underestimate the emotional weight of the last week in an old place, when every goodbye lands harder than expected.

And they consistently overestimate how much they can do themselves on moving day. The gap between "we can handle the big furniture" and the reality of a staircase, a sofa, and a tired back is where most moving day regrets are born.

A map is a mirror

In the end, a collection of thousands of moving routes is a kind of mirror held up to a country in motion. It shows people chasing opportunity, returning home, following family, escaping winters, and starting fresh. The reasons are as varied as the routes themselves, but the underlying feeling is remarkably consistent: a mix of excitement and dread, hope and paperwork, all at once.

If you are planning a move of your own, it helps to start with the numbers before the boxes. My Fast Movers offers a free long distance moving cost calculator that covers routes across the United States, so you can get a realistic sense of cost early, while there is still time to plan properly. The boxes can wait. The clarity cannot.

The quiet engineering of instant play: no install, no sign-up, no wait

Daniel Mercer — Thu, 29 Oct 2026 07:30:34 +0000

The quiet engineering of instant play: no install, no sign-up, no wait

Open a game on your phone and count what happens before you actually play. There is usually a store page, a download, a progress bar, a permissions screen, an account form, a tutorial you cannot skip, and then, eventually, the game. Each of those steps is small on its own. Together they are a wall, and most players bounce off it before ever reaching the fun part.

Instant play is the opposite philosophy. You click, and the game is already there. No install, no sign-up, no wait. It sounds simple, but making it feel simple takes real engineering, because the browser is doing all the work that an installed app normally spreads across a download and a first launch.

Why the first five seconds matter

Every barrier before gameplay costs players. Someone has a spare ten minutes, taps a link a friend sent, and if nothing playable appears quickly, they go back to whatever they were doing. The game did not fail. The funnel did.

A browser games site therefore has one job above all others: shrink the gap between curiosity and play to almost nothing. The page itself must be light, the game file must start loading the moment the page renders, and nothing, no login modal, no newsletter popup, should stand in front of the play button.

What "no install" actually costs the builder

Running a game in the browser means living inside constraints that native apps do not face. Memory is shared with every other open tab. The JavaScript engine has to compile and run game code while the page is still painting. Audio needs a user gesture before it can start, which is why a well built browser game waits for your first click before playing a sound rather than failing silently.

Good instant play engineering respects all of this. Games are split so the core loads first and heavier assets stream in behind the opening screen. A puzzle game should not make you download its entire soundtrack before showing the first board.

There is also the question of device range. A browser game cannot assume a flagship phone or a gaming PC. The same page might be opened on a five year old laptop or a budget Android phone. Developers who test only on their own machine ship games that stutter for everyone else. The fix is unglamorous: test on weak hardware, cap particle effects, and keep the default settings modest so the game runs well first and looks pretty second.

Why "no sign-up" is a feature, not a missing feature

Accounts are useful for saving progress across devices, and many players do want them. But making an account mandatory before the first play session is a different decision, and usually a bad one. It tells a curious visitor that their time is less important than your database.

The better pattern is play first, account later, and only when the player has a reason to care. Let someone finish three levels of a puzzle game, then offer to save their progress. By then the account has value to them, because there is something worth saving. Before that moment, it is just friction dressed up as onboarding.

The catalogue problem nobody talks about

Instant play gets harder as a library grows. A site with a handful of games can hand curate everything. A site with tens of thousands of games faces a different problem: how does a player find the one game they actually want, without scrolling through pages of near duplicates?

Search has to understand intent, not just titles. A player typing "spot the difference" wants a specific kind of game, and a catalogue that returns unrelated results because of a shared keyword has failed them.

The practical answer is a mix of clean metadata, human curation of the front page, and search that tolerates sloppy input. Players misspell game names constantly. A search box that only matches exact titles is a search box that mostly says no.

What players actually get

That lightness is why browser games have survived every wave of app store hype. They are not trying to be the biggest games in the world. They are trying to be the easiest games to start, and for millions of players with a few minutes to spare, that is the only feature that matters.

If you want to see what a library built on that principle looks like, Gameziko offers thousands of free HTML5 games that load straight in your browser, no downloads and no sign-ups required. Click a game, and you are playing. That is the whole pitch, and it is enough.

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

Daniel Mercer — Wed, 28 Oct 2026 07:05:27 +0000

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.

How we test 56,000 browser games without playing them all

Daniel Mercer — Wed, 28 Oct 2026 07:03:56 +0000

Running a portal with 56,000 browser games sounds like a testing nightmare. Nobody can play 56,000 games, and nobody should try. Yet our players expect every game they open to load, respond to input, and actually be playable. Here is how we check that at scale, without a QA team the size of a small town.

The problem with manual testing at this scale

A single tester, playing one game every five minutes, eight hours a day, would need more than two years to cover the catalogue once. By then, games would have changed, new ones would have arrived, and the whole exercise would be obsolete. Manual testing does not scale, so we stopped pretending it could.

The insight that changed our approach is that most game failures are not subtle gameplay bugs. They are crude, structural failures: the game file is missing, the embed points at a dead URL, the game loads but never accepts input, or the game only works on desktop and breaks silently on mobile. Those failures are detectable automatically, and they account for the overwhelming majority of player complaints.

The automated checks we actually run

First, every game page gets a load check. We fetch the page, confirm the embed resolves, and confirm the game asset returns a successful response. A missing file is the most common failure in a catalogue this large, usually because a game provider changed a URL without telling anyone.

Second, we run a headless browser check on a sample of games every day, and on every newly added game. The browser loads the game, waits for its canvas or main element to appear, and sends a few synthetic inputs: a click, a keypress, a mouse move. If the game never renders, or never responds, it gets flagged for human review. We do not need to know whether the game is fun. We need to know whether it runs.

Third, we check mobile rendering. A large share of our traffic is on phones, and games built for desktop keyboards can fail completely on touch devices. The mobile check confirms the game fits the viewport and responds to touch input. Games that fail are labelled desktop-only rather than removed, because honesty beats a broken experience.

What automation cannot do

Automation cannot tell you whether a game is good. It cannot tell you whether the controls feel right, whether the difficulty curve is fair, or whether the game is a thin clone of a better one. For that, we rely on player signals: play time, return visits, and reports. A game that loads perfectly but nobody plays twice is a different kind of failure, and it gets handled by curation, not by testing.

Automation also misses intermittent failures: games that work nine times out of ten and break on the tenth, usually because of an ad or a third-party script loading slowly. For those, we rely on player reports, and we treat a report as a bug until proven otherwise, because players rarely report a game that works fine.

The lesson for anyone with a large catalogue

Test the structure, not the content. Confirm that things load, render, and respond, and let humans handle the judgement calls. A catalogue of 56,000 games does not need 56,000 playthroughs. It needs a small number of reliable checks, run constantly, plus a fast path from player report to fix.

If you run a large content site, free or otherwise, the same principle applies. Automate the crude failures, which are the most common and the most embarrassing, and spend your human attention on quality, which is where it actually matters.

You can see the result at GameZiko, where every game is one click away, no downloads, no sign-ups, and, we hope, working when you open it.