In 1999, I assembled every piece of a client's web presence by hand. Today, I check a status page and wait for someone else to fix it.
In 1999, I was 22, working at Ogilvy Public Relations in Washington, D.C., and had made the mistake of teaching myself HTML.
That made me "the computer guy." And being the computer guy meant I was responsible for things I barely understood—things that, looking back, nobody really understood yet.
One day, the office celebrated the installation of a T1 line. This was a big deal. A T1 delivered 1.544 megabits per second—blazing fast by the standards of the day. We had hundreds of people in that office, and we were all going to share it. By today's standards, that's less bandwidth than a single 4K video stream. But we weren't streaming video. We were building static HTML pages, checking email, and marveling at the speed.
Everything about the web in those days required assembly. You didn't sign up for a service. You built a stack.
The Patchwork Era
To get a client's website online in 1999, I had to coordinate at least half a dozen separate pieces, each from a different provider.
First, you needed a domain name. Back then, that meant Network Solutions—they had held the exclusive contract to register .com, .net, and .org domains since 1993, and they charged $100 for a two-year registration. There was no competition. You paid what they charged, or you didn't have a domain.
Then you needed a server. Not a hosting plan—an actual server, or at least space on one. You found a company that would rent you a physical machine or a slice of one. It came with nothing: no control panel, no security patches, no automatic backups. If you wanted a firewall, that was a separate appliance you rented. Bandwidth was capped, sometimes at just a few gigabytes a month.
Once you had a server, you had to set up FTP access so you could actually upload files to it. Then you configured DNS records to point the domain to the server. Then you uploaded your HTML files. Then you crossed your fingers.
And then there was email.
If you hosted someone's website, you were expected to host their email, too. This was perhaps the most time-consuming part of the job. Web developers became email administrators by default, troubleshooting POP3 connections and explaining to clients why their messages weren't arriving. It was miserable work that had nothing to do with building websites, but it came with the territory.
The search landscape reflected this fragmentation. Yahoo was a directory maintained by humans. AltaVista was the power user's choice. Ask Jeeves let you type questions in plain English. Google existed, but it hadn't yet become a verb. No single company dominated anything.
This was the patchwork era. Every piece of a web presence came from somewhere different, and making them all work together was the job. It was frustrating, time-consuming, and often broken. And we all wished it were easier.
The First Wave of Consolidation
By the early 2000s, the wish started coming true.
GoDaddy, founded in 1997 as Jomax Technologies, had quietly become an ICANN-accredited registrar in 2000 and started undercutting Network Solutions on price. By 2005, they were the world's largest domain registrar. They added web hosting in 2004, and suddenly, you could get your domain and your server from the same place.
This was the race to the bottom. Hosting plans that cost $180 a month in 2000 suddenly dropped to $15 a month. Then $10. Then less. Companies like Bluehost, HostGator, and dozens of others competed solely on price. The technical quality varied wildly, but the price was right, and for small businesses just trying to get online, that was what mattered.
For those of us doing this professionally, we knew the difference. A $10-a-month shared hosting plan wasn't the same as a dedicated server. But try explaining that to a client who saw the GoDaddy Super Bowl commercial.
And then, in 2004, Gmail changed everything.
The Great Unbundling
Gmail launched on April Fools' Day 2004, and many people thought it was a joke. Google offered a free email service with 1 gigabyte of storage—500 times what Hotmail provided. It seemed impossible.
It wasn't a joke. And it marked the beginning of the end of the era when web developers had to be email administrators.
Gmail was invite-only at first, which created an artificial scarcity that made everyone want it. By 2007, it was open to the public. By 2009, it had dropped its perpetual "beta" label to attract business users.
The real shift came when Google launched Google Apps for Your Domain in August 2006. For the first time, businesses could use Gmail with their own domain name. The following year, Google introduced a paid Premier Edition with more storage and business features. Email was no longer something web developers had to manage—it was a service you subscribed to.
Microsoft followed in 2011 with Office 365, combining Exchange Online, SharePoint, and other services into a cloud offering. Enterprise clients who had once run their own Exchange servers—those poor IT departments—started migrating to hosted solutions.
The unbundling was liberating. Web developers could focus on websites. Email became someone else's problem. But in hindsight, this was also the moment when we began handing control to an ever-smaller number of companies.
The Cloud Takes Over
In March 2006, Amazon launched S3—Simple Storage Service—and changed the economics of infrastructure forever. A few months later, EC2 followed, offering virtual servers you could spin up in minutes and pay for by the hour.
Before AWS, if you needed more server capacity, you called your hosting provider and waited for them to provision it. Or you bought more hardware and waited for it to ship. Amazon offered something radical: infrastructure on demand, with no long-term commitment.
The implications took a few years to become clear. At first, AWS was for startups that couldn't afford their own data centers. Then it was for companies that wanted to scale quickly. Then it was for everyone.
Cloudflare launched in September 2010 at TechCrunch Disrupt, offering security and performance features that had previously required expensive enterprise solutions. They gave away a free tier that made basic DDoS protection and CDN services accessible to anyone.
In 2014, Cloudflare started offering free SSL certificates to all its customers—something that had previously cost $50-$200 per year and required manual installation. In 2016, Let's Encrypt launched, making free SSL certificates available to everyone. Within a few years, HTTPS went from a feature to an expectation.
The technical improvements were real. Sites got faster. Security got better. Outages became less frequent. All the things we had wished for in the patchwork era were coming true.
But the infrastructure was consolidating in ways we didn't fully appreciate at the time.
The Oligopoly
Today, when I set up a new client website, I'm typically interacting with just a few companies.
Cloudflare handles DNS, SSL, CDN, and a web application firewall. They issue the SSL certificate automatically when I point the DNS to them—I don't apply for anything or install anything. Amazon Web Services or Google Cloud provides the underlying server infrastructure, often through a managed platform like Cloudways. Google Workspace or Microsoft 365 handles email.
That's it. Three or four companies instead of a dozen.
Technical experience is vastly better than it was in 1999. Sites load faster. Security is stronger. I spend far less time on maintenance and firefighting than I used to. The infrastructure mostly just works.
But here's what I've come to realize: I've traded the chaos of the patchwork era for dependency on an oligopoly.
This became painfully clear in October 2025, when Amazon's US-East-1 region—the largest and oldest AWS data center cluster—experienced a major DNS failure. The outage cascaded through services that depended on DynamoDB, taking down ChatGPT, Signal, Coinbase, Fortnite, and countless other services. It lasted about three hours.
There was nothing I could do. My systems were fine. The servers I actually manage were running perfectly. But because those servers depend on infrastructure that ultimately routes through AWS, my clients' sites were affected anyway. I couldn't call anyone at Amazon. I couldn't escalate a ticket. I checked the status page and waited.
A few weeks later, in November 2025, Cloudflare experienced a major outage due to a bug in its bot management system. It took down X (formerly Twitter), parts of OpenAI's services, and thousands of other websites—including, ironically, Downdetector, the site people use to check if other sites are down. The Cloudflare status page itself was briefly inaccessible.
Then, in December 2025, another Cloudflare outage—this one caused by a configuration change meant to mitigate a security vulnerability. Twenty-five minutes of global impact.
In each case, my role was the same: monitor the status page, communicate with anxious clients, and wait for someone else to fix the problem.
This Isn't What the Internet Was Supposed to Be
I don't think anyone planned for this.
The internet was designed to be decentralized—a network of networks with no single point of failure. The architecture was intentionally distributed so that damage to any one part wouldn't bring down the whole.
Instead, we've built a system where five or six companies control almost everything. AWS, Google Cloud, and Microsoft Azure provide the computing infrastructure. Cloudflare handles a massive percentage of internet traffic. Google and Microsoft handle most business email. A few registrars control domain registration.
The patchwork era was chaotic and frustrating. I don't miss spending hours troubleshooting email servers or coordinating between six different providers to get a website online. I don't miss the fragility of single points of failure at the individual server level.
But I'm not sure this is better.
When Network Solutions was the only domain registrar, we complained about their monopoly and pushed for competition. We got it—there are now hundreds of registrars. But they all ultimately depend on the same underlying infrastructure, much of it controlled by the same handful of companies.
When hosting was fragmented and unreliable, we wished for consolidated, professional services. We got them, and now when one of those services has a bad day, it takes down a significant portion of the internet.
The patchwork era forced us to understand every piece of the stack. If something broke, we had to know where it broke and how to fix it. The skills I developed in those years—the troubleshooting instincts, the understanding of how DNS, servers, and networks actually work—still serve me today.
But increasingly, those skills are about knowing where to look when something breaks, not about being able to fix it. The infrastructure has been abstracted away to the point where the problems are no longer mine to solve.
The New Reality
Here's what I've learned after 25 years in this business:
The consolidation was probably inevitable. Running reliable infrastructure at scale is hard, and only a few companies have the resources to do it well. The economics favor consolidation. The technical complexity favors consolidation. Customer expectations favor consolidation.
But that doesn't mean we should be comfortable with it.
Every time I route a client's DNS through Cloudflare, I'm adding to their already enormous share of internet traffic. Every time I spin up a server on AWS or Google Cloud, I'm deepening my dependency on their infrastructure. Every time I recommend Google Workspace or Microsoft 365, I'm funneling another organization's communications through one of two companies.
I do these things because they're the right choices for my clients. The services are good. The reliability is high. The alternatives are often worse.
But I'm aware of the trade-off in a way I wasn't ten years ago. The patchwork era was frustrating because everything was my responsibility. The oligopoly era is frustrating because nothing is.
When I started in this business, I could point to a server in a basement in Arlington and say, "That's mine. That's where my clients' websites live." Today, I know my clients' sites are running on infrastructure somewhere, probably in Northern Virginia, but I couldn't point to it if I tried. The abstraction is complete.
I don't miss the pager I wore in 1999. I don't miss the midnight phone calls about crashed servers or the trips to Barnes & Noble to find answers in technical books because Google wasn't useful yet.
But I do miss the sense that I understood the system from end to end. I miss being able to fix things myself. I miss the feeling that the infrastructure was mine to manage, not someone else's to manage on my behalf.
The internet we've built is faster, more reliable, and more secure than the one I started with. It's also more fragile in ways we're only beginning to understand—because when the systems that millions of websites depend on fail, they fail big.
We wished for the patchwork era to end. We got what we wished for.
Be careful what you wish for.