Well obviously some people would pay. The hurdle that a company needs to clear is getting enough people to pay to support both an engineering staff and the infrastructure costs.
Do the math on how many people are necessary to run a web site with on-call rotation, minimum moderation, and someone to run the business. The number of $2/month subscription required to make that work is prohbitively high.
> but perhaps lots of smaller, focused social networks at $2/pop could work
Even large, free, well-funded social networks are failing to get significant traction or running into echo chamber problems (Bluesky).
I've been hearing for years that a paid social network would work, but if the unpaid social network competitors can't get any traction, what makes you think adding a $2/month signup hurdle would improve the situation?
If you want to see a real-world example of people squirming out of their claims that they'd pay for ad-free services, take a look at any HN thread discussing YouTube premium or their ad-block evasion efforts. The price for ad-free YouTube is reasonable for as much as people watch it, yet when cornered the same audiences who claimed they'd pay for an ad-free version suddenly come up with a multitude of new excuses for why they're refusing to pay. My personal favorite claim (which invariably surfaces in every thread) is when people say they would happily pay for YouTube premium if they weren't so aggressive about adblockers.
but if you want to build a social network and aren't dreaming of being gazillionaires for it (which is quite reasonable), then you can get by very easily. how do I know this? because... well it's being done successfully. not was done successfully, is done successfully.
you can probably even get people to help out on it.
you can build a social network with a dedi running nginx hosting your Python application running on a Linux box backed against Postgres (and redis for session storage, although even that is a bit overkill) for like $80/month deployed with a "deploy.sh" script that you run to kick the damn thing into running (Docker is used in dev only, but could easily work here). should you probably add health checks or whatever? yeah. it still works really well.
this scales well past the 100k users mark.
what about video/images/etc? well, this nginx server happily sends out user uploaded video storing them as files on a bog standard ext4 filesystem. backups exist of the site.
the "stack" i mentioned here isn't fancy or particularly tightly optimized, it's in fact pessimized in a lot of ways. hell I know there were a gazillion ways we could improve performance of our application. show the backend app to a game dev and they'd probably want to start strangling people with how poorly optimized most of the actual app is.
and still, it scales well.
again, I stress that this isn't some theoretical idea, this is actively being executed. the entire venture makes money for the team from the users who willingly (and unforcibly in order to use the service, the actual site is free to use in its full form) give money. this isn't ZFS. this isn't Rust. this isn't using some blue-green deployment. this isn't spending hours toiling away at which sysctl to set to squeeze every last cycle out of each box. this isn't behind some massive CDN with "internet scale" boxen or even (for the video serving part) behind any anti-DDoS service.
it's just a matter of doing actual engineering and being willing to actually build the things you want to build.
So I totally agree with your approach.
i think the big thing though is that it's a community and so people are actually willing to support that even if it means the amount of 9s of availability is slightly fewer (although in practice, many providers bust right through their "9s" SLAs without a care in the world) and given a migration from a VM provider to the dedi occurred, migrations obviously can happen if failure presents itself.