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.
Joking aside, this seems to make perfect sense. I spend a decent chunk of time in New York, Boston, and California, and have noticed that Seamless xor GrubHub seem to be well-populated in each location.
My bigger surprise is that the GrubHub CEO will become the CEO of the combined operation- in NYC at least, Seamless has always seemed like the far bigger operation. And GrubHub's web site was painful to use for a long, long time.
I wonder if this means Seamless are closing their offices in Utah?
Slightly worried. When GrubHub acquired campusfood.com, which had the best coverage in my area, they ended up losing almost all of the restaurants in my city. I called them up a couple times and GrubHub claimed that they would be coming soon, but in the end I assume the deals fell apart I was left with many fewer ordering choices.
This is because campusfood.com charged much lower rates than GrubHub does.
I was told by a few restaurant owners that when GrubHub came along, they tried to renegotiate the restaurants to a higher price point, which caused a lot of turnover.
I wonder about the extent to which the GrubHub/Seamless model will prevail and the extent to which the ChowNow model will. My brother works for the latter, and now that I know what to look for I've seen a fair number of NYC restaurants using "their own" ordering systems.
I think the market will be able to support both models for quite some time, as Seamless/Grubhub will never leave high population density markets until delivery problem is solved.
What's the difference? At a glance, it looks like Seamhub organizes everything under their brand, whereas ChowNow makes a custom app for every restaurant.
The latter seems nice if I already have a restaurant in mind, but if I'm too lazy to cook on monday night, I'm not going to go through the apps one-by-one.
I'm fairly certain that Grubhub also allows (and powers) restaurant ordering on the "restaurant's website" -- essentially it brings you back to a Grubhub page but it can be directly linked from the restaurant's site.
This merger would be great for the rising food tech industry. It opens the door to disruptive solutions to revolutionize the model that was created by these two companies. The continued lack of innovation in the space is precisely the reason we decided to build a curated lunch subscription company that works with the toprestaurants in cities to introduce foodies to an amazing variety of options and for companies to have an inexpensive way to compete with Google when it comes to providing lunch for their employees. We're looking forward to seeing the space evolve as a whole!
I have to disagree if only b/c of a differing point of view. As a NYC restaurant consumer and not a restaurant tech provider, this merger is bad for me because it's lowering competition and will most likely just result in me paying higher prices (either directly or indirectly) for delivered food.
Seamless is one of my favorite companies. I literally order food through them every day and I have always been pleased with the speed and design of their website and apps. The more you think about it, the more this appears to be a an amazingly good business (a "tax" on takeout for making it easy!) with important first mover advantages. Whoever puts together a big sales force first will saturate the low hanging fruit, and then network effects kick in after that. So I can see how this merger makes sense. I just hope that the seamless engineers and designers don't leave now.
I started reading this and i kept thing, why the hell would GitHub be buying a food startup! I know they're doing well but this is really beyond developer tools.
Running a restaurant is a tough business, so is running a restaurant-based tech business. Probably for the same reasons-competition!
For me Grubhub was a consumer business and seamless an enterprise business. So not sure how this merger makes sense, unless both companies were seeing slowdown in growth and had to combine some of their operations.
Both companies primary asset at this point is online ordering relationships with a ton of restaurants. There is a significant network benefit to having a larger list of restaurants in a given area, as your service becomes synonymous with ordering food.
I've been told by lawyers that M&A activity usually precedes an economic uptick in a sector. If that's true, then today is a pretty good day to be in tech.
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'