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.
I can only see giving up on Uber Eats as being foolhardy, that is a profitable business with a solid business case, yet lacking those other features would not really cause me to prefer traditional taxicabs telephone dispatch over using an app.
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.
Delivering time sensitive goods from many locations to many other locations is not an easy business model. Especially when you do not control the provider of the sensitive goods or the delivery provider.
Logistics is a tough business so I’m bearish on Uber eats.
eBay looks like a platform that is at least an order of magnitude simpler: No realtime data streams like GPS updates, no matching algorithms, no demand-based pricing or incentives, no ETA calculations. Uber is operating in the real world which means that weather, traffic, protests, construction, events and so on affect the operation.
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.
eBay can get away with relying on third parties for advertising, selling, and transporting goods. They are just an online marketplace.
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.
eBay is arguably a bad example because they sure could do with a proper overhaul of their software that is halfway modenised with a bunch of rough edges accumulated over decades.
I will agree that 'receipts' is part of the core product and should be retained. I didn't mention it because I'm sure we can agree it's within the capabilities of a 30-person team!
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.
This kind of "how hard could it be" analysis is what causes people espousing it to go surprised-Pikachu-face when their nose is ground into fractal complexity requirements. The closer to the coalface you get, the more "huh, who would have thought?" is murmured. A huge chunk of this comes from only thinking about happy path logic in one setting.
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.
I mean this is still arguing over 3 orders of magnitude difference in employee count though. Uber is incredibly heavy on non-"provides a ride from point A to point B" compensations.
Due to the lack of Operations having a real seat at the social hierarchy table at most companies, it isn't hard to see why you can have such a vast difference when dealing with many jurisdictions.
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.
Scheduled rides never actually allocates a driver for me; just a time range and it books a normal ride right when that range starts. Then the driver comes late!
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.