Thanks for this post. I do a hard eye-roll every time I read one of these "Hey, I could build that company's website in a weekend" or "They should only need a few engineers to keep it running" type posts. If anything it just shows that the commenter has 0 idea what they're talking about.
I'm not at all saying that there isn't a good amount of "fat to trim" at large companies, but often times the hard work at these big companies is making a difficult problem (or, rather, set of problems), especially at scale, look trivially easy.
An example I think proves this: In Austin, TX, Uber and Lyft stopped operations in the city for about a year in 2016-2017 when voters passed a law requiring fingerprint checks (the state legislature eventually overrode this law, which is a common feature of Austin city-Texas state relations). During that time, Austin was flooded with a host of startup rideshare apps, some funded by some technology high-fliers. Even though I liked to use the RideAustin app because it was a non-profit, paid drivers more and funded a charity I support, there is no denying the apps were a far, far cry from Uber and Lyft's apps. Even after a full year there was really no comparison in the quality of the apps.
Just the ride-sharing part of Uber does about 15 million rides a day, in thousands of cities, each with different regulations and legal frameworks. Uber on-boards about 50,000 new drivers a month. Anyone who thinks this can all be managed with "15 engineers" has not thought through the problem.
I remember that time quite well. These alternative apps would always fail over the weekends when demand skyrocketed. They just didn’t work, when most people needed them the most (drunk and trying to get home from bars/clubs). That really hurt their reputation in my eyes and in the eyes of others like me (which in Austin was a lot!). I personally remember wandering around at 4am trying to get a ride back… not an experience you can forget easily.
It also wasn’t just a single weekend thing. These other apps had almost a year to fix themselves and they couldn’t. I guess they just couldn’t muster the capital to build something really solid. But in any case it just made it very clear that this isn’t an easy problem. And when Lyft/Uber came back, the other apps were dropped immediately lol.
> These other apps had almost a year to fix themselves and they couldn’t. I guess they just couldn’t muster the capital to build something really solid.
They really didn't have time or money because everybody simply assumed Uber/Lyft would use their gigantic piles of VC cash to come back shortly and sweep everybody aside even at a loss.
The most important factor that is completely lost in this argument is "scale".
Simple looking things are very complex at large scale.
Even if no new features were built, the current api and apps won't scale to meet the demand as the user base continues to grow. And at any point in time there are thousands of bugs that need to be fixed within months before they cause big issues. 15 engineers will take years to fix them.
Another big factor is cyber security. This alone will require more than 15 people. Monitoring and defending against active threats, updating libs with patches and migrating from deprecated dependencies spanning 100s of services.
Uber was designed to be incredibly overcomplex and scaled from the beginning; you can read people’s accounts of the fancy technology they invented to scale other employees’ stuffing code in nonstop. Of course, those other employees had no reason to write that code, and were just doing it because Uber had a lot of money and decided to hire a lot of people to do random busywork.
If “it could be done in a weekend with less people” is true for anyone it’s true for Uber. They should be replacing systems with ones that may scale worse but are cheaper. Scaling=complexity comes from companies like Google/Meta where the engineers practice promotion-based development.
The problem is legal regulations. Wanna know why SAP is so successful despite their software being practically a legend for horrible UI, slowness and other nightmares at an absurd-seeming price point? Because they invest an absurd amount of money into lawyers, process engineers, developers and QA to keep track on law, judicial precedent and XO changes all across the world, so that their customers only have to pull in the latest monthly update and their processes (assuming they didn't deviate too hard) are automatically compliant with all possible kinds of bullshit.
Uber, AirBnB, Amazon FBA and other globally active marketplace companies deal with the same thing - their business is in facilitating other people's business without having to think about local laws and regulations.
Payment alone is a real hard thing: people wish to pay with whatever payment card scheme is most popular in their specific home country - which may not be the usual Mastercard/Visa duopoly -, they may wish to do so in wherever country they are at the moment, there may be international sanctions at play, different regulations about CC fees, clawback periods, taxes, VAT...
Uber was mainly successful by just ignoring the regulations nobody liked and hoping it’d work out, though. It really looks like they just managed to convince everyone that taxi routing is hard and can only be done by hiring 1000 geniuses to write 1000 queueing systems in Scala.
Wasn't Uber famous for shirking regulations until it had cornered markets?
And FBA appears to be borderline fraudulent for both producers and consumers as Amazon comingles inventory with no guarantees.
That said I can see the legal-based marketing pitch. Not sure how well companies who advertise that actually deliver. There's also the risk it becomes theater or regulatory capture
They're not saying it would take 15 to build, they're saying that maintaining it does not take nearly as many staff as they currently have. Which is correct: if Uber is simply a rideshare company, then with the technology established it should be winding down it's dev teams.
If it's instead a "every market" company then it should be doing that with its considerable on-payroll staff.
I mean I'm reading that as hyperbole - the point is that the head count to keep it running should be a lot lower then the head count to build it, keep building it, etc.
I'm not at all saying that there isn't a good amount of "fat to trim" at large companies, but often times the hard work at these big companies is making a difficult problem (or, rather, set of problems), especially at scale, look trivially easy.
An example I think proves this: In Austin, TX, Uber and Lyft stopped operations in the city for about a year in 2016-2017 when voters passed a law requiring fingerprint checks (the state legislature eventually overrode this law, which is a common feature of Austin city-Texas state relations). During that time, Austin was flooded with a host of startup rideshare apps, some funded by some technology high-fliers. Even though I liked to use the RideAustin app because it was a non-profit, paid drivers more and funded a charity I support, there is no denying the apps were a far, far cry from Uber and Lyft's apps. Even after a full year there was really no comparison in the quality of the apps.
Just the ride-sharing part of Uber does about 15 million rides a day, in thousands of cities, each with different regulations and legal frameworks. Uber on-boards about 50,000 new drivers a month. Anyone who thinks this can all be managed with "15 engineers" has not thought through the problem.