Uber's primary barrier to entry is a network effect - if more cars are on Uber that means more word of mouth for Uber less people interested in the other app which means less drivers interested in the other app. They reinforce this not by pure exclusivity deals but by paying drivers who drive more on Uber higher rates (which is a tactic I've seen in the stock photo industry as well, which is also reliant on a marketplace model where a big player brokers access to lots of individual contributors.)
Its secondary barrier is that getting quality software right is more expensive and harder than it looks and benefits from economies of scale. (I don't trust Uber further than I can throw my cell phone but the app is far slicker than Lyft or Karhoo or whatever.)
That's not insurmountable but it's nothing either.
> more word of mouth for Uber less people interested in the other app
This is branding, which I mentioned. Or am I missing something?
> Its secondary barrier is that getting quality software right is more expensive and harder than it looks and benefits from economies of scale.
I'm not sure this is true. The software of Uber does not need to scale larger than, say, the size (in users) of a city. Phrased differently, a city is a natural sharding point. Of course, there is software that needs to use the full dataset (for statistics etc.), but this software can run in batch mode.
No no, wrong type of scale. I'm talking economies of scale.
Uber needs to pay N SFBay-area engineers upwards of $200,000 USD/yr (including health expenses, employer-side taxes, and other overhead) for N years in order to build a well-functioning, city-scale software ecosystem - including server software, devops and maintenance tools, payment provider integration, antifraud efforts around payments, client software on multiple app stores, internal tools for the support team, business tools for the traveling consultants who want easier expense report receipts, all sorts of fun data collection for the business analysts, and all the ongoing maintenance and operations costs associated with that mountain of code. With all that effort expended, all those millions spent, they have a bunch of software they can deploy to one, single city and do a top-notch bang-up job of it.
But now this $N million piece of software can be deployed to its second and third and three-thousandth locality with little more than extra computers, some clever sharding work, and maybe some localization: a puny fraction of the original development effort.
If they need a whole new country, throw in some more internationalization/localization and maybe a new payment provider integration.
Those are the economies of scale. Every feature that Uber adds for $N in developer time is hundreds of times more impactful than if Single City Carshare [tm] were to add it, even if they can use cheaper developers outside the Bay Area.
Of course, there are diseconomies too (if only because of managing additional headcount on the per-city operations side of things), but as you said, cities are a natural sharding point, and this keeps those diseconomies down.
Then perhaps I am the only one here who is not convinced of the complexity of Uber's software. Basically, it is just a CRUD application, with some realtime features to make it look a little more sexy. Yes, software like that could cost on the order of millions, but there are lots of companies/investors who could cough up this kind of money without even blinking. I just don't understand Uber's huge valuation. They seem to have no secured business position, other than by branding (and perhaps a little by binding their "employees").
Its secondary barrier is that getting quality software right is more expensive and harder than it looks and benefits from economies of scale. (I don't trust Uber further than I can throw my cell phone but the app is far slicker than Lyft or Karhoo or whatever.)
That's not insurmountable but it's nothing either.