Seamless always struck me as the far better option. Here in NYC, radial distance is almost useless to define delivery areas. On GrubHub and Delivery.com, I would often see restaurants on the other side of the river show up as in my area simply because of straight line proximity. Somehow Seamless knows which restaurants actually consider me in their delivery area.
The most curious thing about Seamless was they were constantly running promotions with a code that only worked in their mobile app. I don't know if this was meant to help them test or what, but I think there's a huge risk consumers will interpret that sort of thing as 'penalty for ordering in the comfort of your web browser' instead of 'bonus for ordering with a mobile app'
I've written a system that handled delivery areas like this. Restaurants would draw a polygon that showed where they'd deliver. It took 2 people about a day to handle this.
I'm sure that if GrubHub wanted to, they would have done this also.
Although I don't have a huge amount of experience with it, GrubHub always seemed like the inferior option. For a long time they didn't even save credit card details.
It is funny that you feel this way. I started a restaurant CMS (http://sourceforge.net/projects/menube/) years ago, back then GrubHub was a crappy jsp website and a competitor. I even offered to share my software with them:)
I am impressed with their success as a business, technology has never been their strong suit, apparently despite having grown to hundreds of employees.
US addresses in major cities (where these companies operate) is largely solved, though. You can just defer to Google Maps (who have the best geocoder I've ever used- still) or set up a GeoCommons geocoder locally, which isn't anywhere near as good, but does work with well formatted addresses.
Not at all. <Street Address> <Apt Number> New York NY 10027. It would present me with three "corrected" options that were all the same, and then when I chose one it would send me to an error page.
Speaking from experience... apartment numbers are one of the most difficult things to process correctly when geocoding, particularly if your service is backed by Google. The experience you describe sounds exactly like someone didn't correctly handle the edge cases surrounding subunit numbers.
I spent quite some time banging my head against these issues for a former employer. Lots of trial-and-error was employed to build up a basket of test cases around apartments. Certain addresses remained intractable.
The most curious thing about Seamless was they were constantly running promotions with a code that only worked in their mobile app. I don't know if this was meant to help them test or what, but I think there's a huge risk consumers will interpret that sort of thing as 'penalty for ordering in the comfort of your web browser' instead of 'bonus for ordering with a mobile app'