And then there's Uber self-driving. Uber AI; Uber electric airplanes. Uber freight, Uber restaurant delivery, Uber grocery delivery, Uber this and Uber that. Oh, and Uber scooters.
Uber eats? Scooter integration? Mass transit support? Scheduled rides? Commuter cards? If you were building the app with 30 developers you'd simply not bother with those features.
Uber has 3x the headcount as eBay.
Uber has to market themselves which needs local expertise, if nothing else to liaise with a local PR firm. Then they need local legal expertise to actually operate in the country (eBay transactions happen online, and the transport agency hired by the seller figures out how to get the package to its destination). Uber then has to have maps for every country it operates in, as well as change their standards to match local expectations.
The eBay business requires no boots on the ground, Uber Eats does because they have to equip riders. And eBay has almost no market-specific laws/regulations which change every couple of months to worry about.
I think eBay doesn't process payments, that is outsourced to PayPal.
It looks like eBay is in about 25 markets, Uber is available in 85 countries.
Serious question: Why does eBay have so many employees? It's just a search engine for a user generated product catalog where users can place bids on the items. My guess is that most Uber employees aren't high-paid developers, it is more likely that they are in support roles.
I ignored the other stuff because I don't know WTF "pickup special cases" or "on-trip experience business logic" or "growth features" are. So I'm not informed enough to guarantee they aren't part of the core product offering - although you can probably guess my intuition on the matter.
The software that runs the world and gets actual work done day-in, day-out behind the scenes, is riddled with edge case handling. In really mature codebases impacting many stakeholders (not just direct users), the product team can categorize 1% or less of the stakeholder population by a tiny fraction of a commonly-used feature set they use. On that basis, the coding and maintenance effort for the edge cases can sometimes outweigh the sliver of features used by that sub-population of stakeholders.
We aren't talking about a web scraper or run of the mill DevOps here. Anytime you work with lots of business rules in multiple jurisdictions impacting the same processes, the edge case counts go up rapidly, and combinations of processes that you never thought would intersect but are forced to by specific jurisdictions also appear more frequently.
Here is how it works in most of my clients. Management is at the top of the heap. Business/sales/marketing comes next. Developers/engineering after them. Way down at the bottom of the heap, sits Operations. They're the "grunts".
The default dynamic is developers code up a system and toss it over the wall to Operations. When informed by operations of some edge case that comes up frequently on the sad path, developers roll their metaphorical eyes and tells Operations to "just" develop and follow some "SOP".
Cue "One Decade Later..." in French accent meme...
After enough of those edge cases over enough time, it isn't hard to see why all those manual intervention edge cases result in an operations-oriented staff bloat. These are especially challenging to address, because everyone is looking for a silver bullet and very few people in charge of writing checks will accept the reality that this is every bit as much technical debt as the code that runs on the systems, and working off that debt with interest is a slog of expensive unwinding.
Uber gets hit on multiple fronts with this dynamic. More jurisdictions, in an incumbent industry that has accreted more baroque government interfacing, that has simultaneously famously resisted making any of its relevant data available in any form whatsoever beyond paper and microfiche. Sometimes it will take more people than you can imagine.
There's legitimately a reasonable argument that Uber rides has a worse business case than Uber Eats. If I were in Uber's shoes I would be clinging onto both.
Logistics is a tough business so I’m bearish on Uber eats.
At least that’s what Uber recruiters would tell me when trying to recruit.
I reaaaaly wouldn’t assume its a profitable business unless you get some data from a few “normal” (i.e., not pandemic impacted) quarters.
Delivery is the first thing people will cut down on if we get a recession as well
[1]https://www.wired.com/2015/09/whatsapp-serves-900-million-us...
That's after shitting on compliance for years as part of your business model.
McDonald's restaurants have handicap accessible ramps but they don't staff ESL speakers. Apps and web services are no different.
Clubhouse, for example, isn't accessible to the hearing impaired and that's ok.
Uber specifically would definitely fall under a "public transportation" service - accessibility is non-optional if someone decides to sue. [2]
[1] https://www.ada.gov/2010ADAstandards_index.htm
[2] https://www.businessnewsdaily.com/10900-ada-website-requirem...
Firstly that is just plain incorrect in a lot of areas (of business) and jurisdictions. Secondly your outlook on accessibility is just ... SMH and walks away from keyboard.
Do you think complexity of Uber is comparable to that of Whatsapp?
There is a big difference here -- revenue. Real transactions. Financial reporting. Country-by-country regulations and reg reporting.
- iOS rider app
- android rider app
- iOS driver app
- android driver app
- ride/driver matching
- routing/supply
- security/compliance
- fraud detection/prevention
- backend rides services
- backend user services
^ 10 teams of at least 10 people off the top of my head. Amazing how underestimated engineering resourcing needs are.
Wow that was easy.
That is because its very well supported on both platforms, and one of the few language ecosystems that can actually create native looking/acting applications on both.
Yes, the initial development may be a bit slower, but that is common with C++ because what the smart people are doing is usually creating an application specific "language" out of C++. Then once that core bit is done the actual development would probably outpace many of the other choices. I've done this a couple times with native development toolkits, the "customer" in one case was really questioning how much work was actually going on when 1/2 way through the contract it barely had a single "screen" in a data collection/reporting application working. But, then another few weeks went by, and literally in the space of about 2 days the application went from looking like it had just been started, to being basically feature complete. That is because the C++ engine was complete and it took ~12 hours to fill out the few 10s of thousands lines of boilerplate ui descriptions that actually formed the UI (in that case it was a custom textish/declaritive application description language, most of the c++ code was parsing it and doing layout/drawing in response. Super happy customer too, once they understood that their inhouse "IT" people could update/change the app with little more than a text editor against some fairly simple to understand rules).
And many of the functions the GP was asking about are the kinds of things one could contract out. Aka, why not just use google maps API for the routing/etc.
Frankly, given what I saw a couple years ago when I went poking around in the iphone app store, it seems just about every region taxi company had reimplemented large parts of the uber interface in their own apps. Maybe not always as slick, but the core parts were in many of them, and I doubt random regional taxi companies can afford the engineering effort uber apparently is spending on.
If you're looking to trim fat - surprisingly - there might be better opportunities outside of engineering.
This comment is insane for any real app in the real world transacting in real dollars. There are a hundred countries with 100 regulations. Accounting/P&L/bookkeeping for the United States ALONE would take 30 developers for a revenue base this size.