I have also known, and seen first-hand, companies that neglect their code bases for a long time, and then have to let go entire teams once the quality bar is raised, or once they fail to adopt a proactive attitude towards defects.
Startups are not small companies. Startups are companies created with exponential growth in mind, and if your product is not prepared for that kind of growth, you do not need startup scale funding. You could do fine with small business funding. Unless you can find some chump that will buy your small company at a startup price, usually by inflating the payroll with a lot of redundant employees right before selling.
It turns out building scalable software most of the time is not about making the kind of investments you talked about. It's about designing each feature with scale in mind. Then, unless the startups you talk bought multiple geographically distributed datacenters and deployed their own submarine cables, they were not working at that scale. Don't exagerate.
> Then, unless the startups you talk bought multiple geographically distributed datacenters and deployed their own submarine cables, they were not working at that scale. Don't exagerate.
No, you’re right. Totally exaggerating, but that was seriously their mindset. “We can’t use an SQL database, it won’t scale to a billion users!” I strongly suspect the team talked about where they’d deploy their data enters and the risks of using other people’s cables - only _partly_ in jest.
The one I had in mind specifically while writing that were fighting with sharded MongoDB clusters, eventual consistency, and auto scaling app server fleets, while not having 1% of the user base I support with a more complex app on a handful of t3.medium spot and on demand instances, and a dB.t3.large rds aurora database. I know it’s always hard to reliably forecast when your current solution’s vertical scaling capability will runout and you need something more scalable than a stateless monolith with a vertically scaling SQL database behind them, but they were easily three maybe four or more orders of magnitude short of that inflection point. I have zero doubt their kinda good idea could have scaled to high seven or low eight digits of revenue before needing any heroic platform architecture. Well before that became a necessary problem to solve they could have had a 50 person engineering team with leadership who’d done it before to solve that problem for them.
And I totally agree with your “neglected codebase” problem too, I’ve spent the last 18 months or more on a “rewrite the old Grails backend code in Java” journey, which has gone about as smoothly as they always do /\/\/\/\... We’re now finally in a place where the Java platform is as good as the old one in most areas, and betting in some important ones. But of course we now have a bunch of “legacy clients” who are not (and may no ever be) migrated of the Grails platform, and I’m fighting very hard to avoid the worst of the “neglected codebase” problems that’s gonna throw me over then next few years while we solve the legacy client problem (and COVID isn’t making it any more likely that some of out government clients will upgrade is the need to pay to do so...)
Startups are not small companies. Startups are companies created with exponential growth in mind, and if your product is not prepared for that kind of growth, you do not need startup scale funding. You could do fine with small business funding. Unless you can find some chump that will buy your small company at a startup price, usually by inflating the payroll with a lot of redundant employees right before selling.
It turns out building scalable software most of the time is not about making the kind of investments you talked about. It's about designing each feature with scale in mind. Then, unless the startups you talk bought multiple geographically distributed datacenters and deployed their own submarine cables, they were not working at that scale. Don't exagerate.