/Technology

There's a quiet addiction in software development. It doesn't show up in bug reports or sprint retrospectives. It lives in architecture discussions that drag on for hours, in layers of abstraction built for problems that don't exist yet, in microservices created for an app with two hundred users. It's called over-engineering, and it's probably the biggest waste of technical talent in our era. The irony is that the products that today require massive infrastructure, servers spread across continents, hundreds of engineers, data pipelines processing petabytes per second, all started with solutions any computer science student could write over a weekend. The secret the tech industry prefers not to advertise is this: success rarely came from the engineering. It came before it. > "The Facebook 1.0 wouldn't have survived an average e-commerce Black Friday. And it was still enough to change the world." ## The myth that great tech is the foundation When we look at giants like Google, Netflix, Facebook, or Twitter, we tend to imagine that somewhere in their early days, there was a brilliant technical decision that made everything possible. An elegant algorithm. A visionary architecture. A database choice that anticipated decades of growth. The real story is considerably less glamorous. What these products had in common wasn't technical sophistication. It was clarity of purpose. They knew exactly what small problem they could solve, solved it well enough, and shipped the thing. Serious engineering came later, pulled in by success, not as a condition for it. When I first started studying these companies, I kept waiting to find the "genius moment" where everything clicked technically. It doesn't exist. What I found instead was a lot of duct tape and conviction. **Google, 1998:** Two PhD students, a cluster of cheap PCs, and a link-ranking algorithm. The interface was a text box and a button. No personalization, no accounts, no recommendations. Just results. **Facebook, 2004:** Pure PHP, a MySQL database, shared hosting. The site crashed regularly under minimal load. The main feature was a profile with a photo and a few text fields. There wasn't even a feed yet. **Netflix, 1997:** A website that took DVD orders by mail. No streaming, no AI recommendations, no original content. A glorified online store with a movie catalog. **Twitter, 2006:** Jack Dorsey's idea sketched on a napkin. SMS for groups. The first prototype was built in a single hackathon day. The 140-character limit existed because that was the SMS limit. ## The flaws that should have killed each of them We're not talking about small imperfections here. We're talking about structural failures that, by any standard engineering best practice, made these products unviable. ### Google and the cardboard server problem The first Google servers were literally assembled in cardboard boxes by Page and Brin themselves, in Page's Stanford dorm room. Hard drives were bought secondhand or borrowed. The infrastructure crashed regularly. The original PageRank code was written with zero concern for scale, because the goal was to prove the concept, not to serve the world. By 1998, Google was indexing 25 million pages on 10 manually assembled PCs. The site responded slowly and went down under any significant load. By 2000, it had become the world's largest search engine, still running on rudimentary infrastructure. Only between 2003 and 2004 did the Google File System and MapReduce papers emerge, architectures that invented solutions that didn't exist because there was no off-the-shelf product for the scale they needed. Serious engineering arrived late, but it arrived. ### Facebook and the crashes nobody talks about Before Twitter was famous for its outages, Facebook was collapsing regularly. Mark Zuckerberg's PHP code, written in a rush in Harvard dorms, had no sophisticated caching, load balancing, or service separation. It was a fragile monolith that grew too fast for what the architecture could handle. In 2006, when Facebook opened registration to all American universities, the site went down for days. The technical response was improvised and chaotic. And growth continued anyway, indifferent to the technical limitations, because the product solved something people deeply wanted: to see and be seen by people they knew. Bom, that's the part nobody frames as a lesson. The product worked not because the code was good. It worked because the idea was right. ### Netflix and the transition that almost didn't happen When Netflix launched streaming in 2007, the technical solution was so limited it only worked in Internet Explorer, on Windows, with a specific plugin that most users couldn't install correctly. The catalog available for streaming was a tiny fraction of the DVD catalog. Video quality was inconsistent. Reed Hastings and his team knew the technology wasn't ready. They launched anyway, because the direction was right even if the execution was imperfect. They spent the following years building the streaming infrastructure, eventually migrating to AWS and inventing cloud engineering practices the whole industry uses today. ### Twitter and the Fail Whale as a cultural symbol Twitter became so prone to failures in its early years that the error message, a whale being lifted by birds, got its own name and became a cultural icon. At traffic peaks like the Oscars or the Super Bowl, the site simply stopped. Not partially. Completely. The original backend was built in Ruby on Rails, an excellent framework for prototypes but with serious concurrency limitations at the scale Twitter reached. The migration to Scala and distributed systems took years and caused deep internal conflicts. But the product grew throughout, because the value was in the idea, real-time public conversations, and not in technical robustness. In my experience, this is the part that's hardest to accept when you're building something. You want to believe that if the code is solid, the product will succeed. But it works the other way around. ## How they evolved, and what that tells us The pattern of technical evolution across these companies is remarkably consistent. It's not a story of early technical vision. It's a story of problem validated first, infrastructure built after, guided by real need and not by speculation. ### From improvisation to invention What distinguishes these companies isn't that they avoided technical problems. It's that the technical problems they faced were scale problems, the best kind of problem a product can have, because it means enough people are using it to create the pressure. Google invented MapReduce because it needed to process the entire web. Facebook created Cassandra, today used by half the industry, because it needed to store user data at unprecedented scale. Netflix built one of the world's most sophisticated recommendation systems because it had the data to feed it. Twitter reinvented its messaging infrastructure because it needed to deliver a celebrity tweet to tens of millions of followers in seconds. None of these advanced technical solutions would have been built if the products hadn't survived with simple solutions long enough to prove they were worth the investment. That's the part worth repeating: simple first, sophisticated later. ### The specific lesson Netflix teaches Netflix is perhaps the most instructive case because its transformation was the most radical. From a mail-order DVD store to a global streaming platform to an original content production studio. Each transition was made with the technology that was available and sufficient for the moment, not the ideal technology for a hypothetical future. Netflix's recommendation algorithm, today one of the most advanced in the world, started as a simple "other customers also rented" list. Deep personalization came when there was enough data to feed it and enough users to justify the investment. Not before. ### Facebook and the humility of the monolith For years, Facebook operated as a monolith, a single block of code that grew like a city without an urban plan. Experienced engineers looked at that code and felt visceral discomfort. It was everything that best practice manuals prohibited. But that monolith allowed Facebook to iterate at speeds impossible for products with more "correct" architectures. Adding a new feature took hours, not weeks. The accumulated technical debt was real and costly. But the cost of moving slower would have been probably fatal at a time when MySpace was still a viable alternative. ## What this means for anyone building something today There's a genuine tension here. This isn't an invitation to sloppy code, insecure practices, or systems that put user data at risk from day one. It's an invitation to be honest about what really matters at each stage of a product. **First:** figure out if anyone wants what you're building. This is the only question that matters before there are real users. **Second:** make the thing good enough that those people can use it and find value in it. **Third:** build for the scale you have, not the scale you imagine you'll have. **Fourth:** as you grow, invest in the infrastructure that real growth demands, guided by concrete usage data, not architectural anxiety. ### The real cost of early over-engineering Building too much too early has costs that are rarely accounted for correctly. Development time is the most obvious: weeks spent building sophisticated caching systems for an app with fifty users are weeks not spent figuring out if those fifty users are finding the promised value. But there's a less visible cost: rigidity. Complex systems are hard to change. And the products that survive are rarely the ones that got it right on the first try. They're the ones that changed fast enough when they discovered the first version was wrong. Aliás, this is what killed a lot of technically impressive startups. Beautiful architecture, wrong problem. Instagram was acquired by Facebook for one billion dollars when it had thirteen employees. WhatsApp was acquired for nineteen billion with fewer than fifty engineers serving hundreds of millions of users. Neither of these products had technically impressive architectures by the standards of the time. They had products people wanted to use. ## Conclusion The history of the world's biggest digital platforms is, among other things, a story about getting the sequence right. Value came before technical sophistication. Scale was a consequence of the product working, not a prerequisite for it existing. This isn't an invitation to carelessness. It's an invitation to be honest about what really matters at each stage of a product. In a product that doesn't yet know if it has users who want it, the most important question isn't "how will we scale to ten million users?" It's "how do we get to the second user?" Engineering is an extraordinary tool. Like all tools, its value depends on being used at the right moment, for the right problem, in the right dose. The products that survived weren't the ones with the best initial architectures. They were the ones that arrived at the right problem in time, with code good enough to prove they were worth existing. The rest, the elegant infrastructure, the distributed systems, the machine learning pipelines, is the reward that comes after. Not the entry ticket.