I came across a discussion about The Browser Company, which reportedly has over 100 people working on their browser, Arc. If we consider that only about half of them were focusing on research & development and marketing, it's interesting to see how a solo developer, known as u/maubg, managed to create a browser that's around 80% comparable in roughly a year. This has made me ponder the reasons behind this disparity. Is it a sign that larger teams are less efficient, or is building a modern browser more feasible for an individual developer if they limit their scope? I'm curious about what factors might explain this gap. Could it be due to utilizing open-source engines, having a narrower feature set, skipping quality assurance, or differences in polish and reliability? I would love some concrete examples of what aspects really scale with team size versus what a skilled solo developer can manage effectively.
5 Answers
Yeah, that last 20% is where it gets tough for many developers. Sure, you can create a user interface that looks fancy, but if the underlying functions aren't there, it falls flat. Plus, handling all the historical quirks of the web makes things even trickier. You'd be surprised how many websites rely on those edge cases without realizing it!
Honestly, trusting a single developer with something as complex as a browser feels risky to me. With all the security concerns, even a basic browser needs heavy oversight and continuous updates. If a solo dev is just wrapping a new UI around something like Chromium, that might not even count as a brand-new browser. It's all about how often they update it and maintain security, which can be a huge responsibility for one person.
Let’s not forget the 80/20 rule—80% of the time and effort often gets spent on that last crucial 20%. And in many companies, a large portion of the staff isn't actually working directly on development. You've got QA, project managers, marketers, and other overhead that can complicate things even more.
Productivity doesn't grow in a straight line with the number of people. More folks mean more coordination and management time, which can slow things down. Also, forking an existing browser isn't quite the same as building one from scratch—you're just adding a layer on a massive project that took decades to develop. Remember, the first 80% of development usually comes together fairly quickly, but it's that last 20%—debugging, documentation, and polish—that can eat up most of the time.
In big companies, you often hear the idea that it takes ten developers to do the work of one. There's so much red tape and multiple layers to get through before something can go live. Each additional person can add complexity, and the hard parts usually involve thorough reviews and ensuring everything meets various standards. That makes solo projects more appealing for rapid development, but they might lack some necessary resources that bigger teams typically handle.
It's true; I think a lot of non-developer roles actually slow down the process!
Exactly! A lot of people don’t consider how compatibility issues can complicate things.