Hyperlocal delivery: address resolution and matching

Postal codes describe areas, not points, which is why they make a poor basis for deciding whether a supplier can deliver to a customer. A single postal code can cover a wide region and, in some countries, contain several distinct localities. When a system matches on the postal code, it usually compares against the code’s centroid — one representative point — and that point can sit kilometers from where the customer actually lives.

Geocoding is the step that avoids this. The Google Geocoding API converts an address into latitude and longitude, and its response can even list the multiple localities contained in a single postal code, which is a direct measure of how loose the area is. Matching on a real coordinate, rather than the area’s centre, is what separates a delivery decision that reflects reality from one that guesses.

hyperlocal-delivery-postal-code-matching-failure

Postal-code matching can reject customers who are actually close to a supplier and accept customers who are outside the real delivery radius.

The failure is symmetrical, which is what makes it costly. A customer near a supplier’s edge gets told no supplier delivers, and a customer who is genuinely out of range gets told yes and then has the order fail later. Both erode trust, and both look like random bugs until someone traces them to the matching layer.

The fix is to resolve the customer’s actual address to coordinates and match on those, which sounds simple until you meet the addresses that do not fully resolve. Real input is messy: misspellings, missing unit numbers, and new streets the map has not indexed yet. The geocoder flags these as partial matches rather than failing outright, and a delivery platform has to decide what to do with them. A few choices keep the experience usable:

• when the geocoder returns a partial match, let the user save the coordinates from a map pin and complete the textual address by hand, instead of blocking the order
• offer a draggable map marker alongside the address field, so an address the database has never seen can still produce an exact point
• keep the resolved coordinate as the source of truth for matching, with the text address attached for humans and labels

On a marketplace we rebuilt this way, the migration went from postal-code matching to full coordinate resolution, with the map marker as the fallback for addresses the geocoder could not pin precisely. The coordinate became the value the availability logic trusted, and the text address rode along for display.

Address data does not stay clean on its own, so resolution is not a one-time step at checkout. Some addresses arrive incomplete, others change, and a coordinate saved manually may need confirming. A scheduled job that re-validates stored addresses keeps the data from rotting between the moment it is entered and the moment a driver needs it.

The Google Address Validation API is built for this: it checks an address against known data, standardizes the format, and attempts to complete missing components, returning the parts it could not confirm. Running it on a cron over saved addresses lets the platform auto-complete what it can and flag the rest for a human, rather than discovering a broken address only when a delivery fails at the door.

If your delivery availability is postal-code-based and customers with nearby suppliers are being turned away, the address layer is usually where the fix lives. Our e-commerce engineering team has migrated a marketplace from postal-code matching to coordinate resolution, and can scope the same for your platform.

Whether a product can be delivered to an address is rarely a pure distance question; on a real marketplace it is a stack of conditions evaluated together. Geography is one input, and the availability check has to weigh all of them before it marks a product as buyable for that customer.

The geographic part rests on coordinate distance. With both the customer and the supplier stored as points, a spherical-distance function such as MySQL’s ST_Distance_Sphere returns the meters between them, which a spatial index makes fast enough to run at request time. When several suppliers cover the same address and offer the same product, that distance also gives you nearest-vendor selection: the order goes to the closest supplier that qualifies on every other condition.

That nearest-supplier result is the input to order assignment. The deeper routing logic lives in our piece on location-based order routing, and the same multi-condition availability calculation feeds route optimization downstream, since the system already knows which supplier serves which address.

How a customer enters their address shapes how clean the coordinate is, and two methods cover most cases. Address autocomplete speeds up entry for addresses the map already knows; a map marker handles the ones it does not. The Google Place Autocomplete widget gives a type-ahead field that resolves a known address to a precise place as the user types, cutting typos and keystrokes. It does not cover everything, so the two methods work best together:

• use autocomplete for addresses in well-mapped areas, where a prediction resolves to an exact point
• fall back to a draggable map marker for new developments, rural addresses, or anything the predictions miss
• show the chosen point on a map for visual confirmation, so the customer can correct a wrong pin before ordering
• leave the address fields editable, since autocomplete often omits unit or apartment numbers

Most e-commerce marketplaces that deliver locally end up offering both, because neither method alone covers every address a real customer will type.

• Matching deliveries by postal code fails because a postal code is an area, and its centroid can sit kilometers from the customer’s real location.
• Resolving the actual address to coordinates and matching on those is the fix, with a map marker as the fallback for addresses a geocoder cannot fully resolve.
• A scheduled validation job keeps stored addresses accurate over time, auto-completing what it can and flagging the rest.
• Delivery availability is a multi-condition check — radius, zone, stock, status, B2B rules, cart, and more — not distance alone.
• When several suppliers cover the same address, coordinate distance gives nearest-vendor selection and feeds order routing downstream.

Hyperlocal delivery rests on knowing where the customer is, and that single fact decides whether the rest of the platform behaves. Postal codes guess at it; coordinates know it. Resolve the real address, give users a marker for the points the map has never seen, keep the data validated as it ages, and treat availability as a stack of conditions rather than a distance check. The platforms that struggle built the storefront, the routing, and the analytics on top of an address layer that was quietly wrong, and spent months chasing bugs that all traced back to the same place.

If you are rebuilding address resolution or supplier matching and want the approach mapped before you commit engineering time, a short technical review will save a round of rework. Talk through your address and matching layer.