Well said. I definitely agree (you’re absolutely right!) that the product will get worse through that re-architecting for enterprise transition.

But the small product also would not be able to handle any real amount of growth as it was, because it was a mess of tech debt and security issues and manual one-off processes and fragile spaghetti code that only Jeff knows because he wrote it in a weekend, and now he’s gone.

So by definition, if a service is large enough to serve a zillion people, it is probably big and bloated and complex.

I’m not disagreeing with you, I liked your comment and I’m just rambling. I have worked with several startups and was surprised at how poorly their tech scaled (and how riddled with security issues they were) as we got into it.

Nothing will shine a flashlight on all the stress cracks of a system like large-scale growth on the web.

> So by definition, if a service is large enough to serve a zillion people, it is probably big and bloated and complex.

Totally agree with your take as well.

I think the unfortunate thing is that there can exist a "goldie locks zone" to this, where the service is capable of serving a zillion people AND is well architected. Unfortunately it can't seem to last forever.

I saw this in my career. More product SKUs were developed, new features/services defined by non-technical PMs, MBAs entered the chat, sales became the new focus over availability, and the engineering culture that made this possible eroded day by day.

The years I worked in this "goldie locks zone" I'd attribute to:

- strong technical leadership at the SVP+ level that strongly advocated for security, availability, then features (in that order).

- a strong operational culture. Incidents were exciting internally, post mortems shared at a company wide level, no matter how small.

- recognition for the engineers who chased ambulances and kept things running, beyond their normal job, this inspired others to follow in their footsteps.