Delivery Service Areas from Google Earth

The problem

Every restaurant location has a delivery area — the geographic boundary it will and won't deliver to. Those boundaries are real-world shapes: they follow highways, avoid the river, stop at the township edge. A radius doesn't describe them. Neither does a list of suburbs.

The people who actually know where those lines fall are the franchisees. But they aren't engineers, and there was no way to get that knowledge into the system without a developer in the middle.

What I built

A KML import and export pipeline for service areas. The workflow:

1. 01Franchisee opens Google Earth — a tool they already know, or can learn in ten minutes.
2. 02Draws their delivery boundary as a polygon.
3. 03Exports it as a KML file.
4. 04Uploads it to the back office.
5. 05The system parses the geometry and turns it into a live service area used for serviceability checks at checkout.

Export works in reverse, so an existing zone can be pulled back into Google Earth, adjusted, and re-uploaded. I also built landmarks — named point locations that sit inside a service area to handle exceptions. A park, a stadium, an office block with no street address. Places customers genuinely order to that a polygon-and-street-address model can't express on its own.

Why it mattered

It moved boundary definition from engineering to operations. A franchisee expanding into a new suburb no longer files a ticket and waits — they redraw and re-upload. That's a whole class of support work that stopped existing.

Related work

I also worked on the serviceability checks these zones feed into — including a bug where switching from delivery to collection at checkout with an out-of-area address silently failed to warn the customer, because the overlap check only ran for delivery. Collection needed the same guard.