Database: I’d use whatever you know and helps you get to market, but abstract it away from the rest of your app so you can swap out later. Lots of good choices here; I’d pick mysql or postgres running on rds. I would also design for sharding by user on day 1 because that can be extremely painful to add later, however, care would have to be taken to ensure it doesn’t slow you down too much early. I’d also just use an rdbms for caching unless it becomes a problem, only then would I reach for redis. I would also avoid a fanout-on-write approach in favor of fanout-on-read. It will save you a lot of headaches later.
Firestore is nice but can get expensive quickly so I’d plan for it to be a temporary thing.
2. Would go for a react native app first but there are lots of options to choose from. Go with tech you know but keep in mind that it’s basically impossible to get a AAA mobile experience on web, and in this space polish really matters.
3. Decentralized social networks never took off because they are too hard to build. Avoid at all costs unless you have some angle (ie you have some novel tech discovered during your PhD). A middle ground could be a centralized network that is open source and makes data portability front and center.
I’ll also say that growth matters a lot here. As a founder I think 20% of the teams headspace should be thinking about engineering. The rest on growth and retention.