Being coal-free is possible. Being fossil-fuel free is harder. Most of Irish energy comes from Natural Gas and Oil - the former is what supplanted Coal, not Wind.

Firefox - the one thing they do not want to work on is the only thing that makes them special.

As your business needs grow, you can start layering complexity on top. The point is you don't start at 11 with a overly complex architecture.

In your example, if your server crashes, just make sure you have some sort of automatic restart. In practice that may mean a downtime of seconds for your 12 users. Is that more complexity? Sure - but not much. If you need to take your service down for maintenance, you notify your 12 users and schedule it for 2am ... etc.

Later you could create a secondary cluster and stick a load-balancer in-front. You could also add a secondary replicated PostgreSQL instance. So the monolith/postgres architecture can actually take you far as your business grows.

You can get all that with a monolith server and a Postgres backend.

Probably should stop after this line - that was the point of the article. It will work at lower scales. Optimize later when you actually know what to optimize.

You're making two assumptions - both wrong:

1) That this is an unscalable solution - A monolith app server backed by Postgres can take you very very far. You can vertically scale by throwing more hardware at it, and you can horizontally scale, by just duplicating your monolith server behind a load-balancer.

2) That you actually know where your bottlenecks will be when you actually hit your target scale. When (if) you go from 1000 users to 10,000,000 users, you WILL be re-designing and re-architecting your solution regardless what you started with because at that point, you're going to have a different team, different use-cases, and therefore a different business.

No. That's not it. In this case, if you properly control for all the factors, it turns out that the odds of Nakamura having that kind of a win-streak (against low-rated opponents) was in fact high.

I know what OP is referring to. Back in the day, a programmer was expected to have built their own toolbox of utility scripts, programs and configurations that would travel with them as they moved from project to project or company to company. This is akin a professional (craftsman, photographer, chef, electrician, etc.) bringing their own tools to a jobsite.

I'm not sure which platforms those companies built their businesses on .. are you equating build an app on iOS or Android with building an app that relies on, say, Facebook APIs and only works on Facebook?

You're being facetious, but OP is right. For software platforms, this has been a constant. It happened with Twitter, Facebook, Google (Search/Ads, Maps, Chat), Reddit, LinkedIn - basically ever major software platform started off with relatively open APIs that were then closed-off as it gained critical mass and focused on monetization.

Yep. It’s a lesson that keeps being re-learned the hard way.

By the way, I also hate the "hello"-only message. I am, however, guilty of writing "Hey. Do you have a second to chat" - typically in cases where either through chat or video conference I want to go through something that is more involved, and I also want some confirmation of understanding and acknowledgement.