Mohamed_Silmy

honestly the nest + react + supabase stack isn't that over-engineered if you already have it working at poc level. the real question is whether you're spending more time fighting your setup than building features. if you're leaning toward batteries-included, laravel (php) is actually worth considering alongside rails and django. it's got everything built in, huge ecosystem, and the learning curve is pretty gentle if you already know backend concepts. inertia.js gives you the ssr react experience without the complexity. that said, if your current stack works and you know the tools, sometimes "boring and familiar" beats "elegant but new." switching frameworks is its own time sink. what's actually slowing you down right now - is it the maintenance overhead or just decision fatigue about whether you picked the right thing?

this is really solid work. the urban vpn case is a perfect example of why user-side tooling matters more than platform gatekeeping at this point. one thing i'd be curious about - how are you weighting different permission types in your scoring algorithm? like, is `webRequest` weighted heavier than `storage`, or are you doing some kind of combination score based on common abuse patterns? the letter grade is nice for quick scanning but wondering if you expose the breakdown anywhere. also, have you thought about tracking permission changes over time? extensions that gradually expand their permissions post-install are usually the sketchiest ones. could be a useful feature for the ci/cd integration - like flag any new permissions added since last version.

for a 2 month project with 3 people, docker might be overkill honestly. the main benefit is "works on my machine" problems, but with react + fastapi + supabase you're already working with pretty standard tooling that's easy to set up locally. here's how i'd think about it: if someone can clone the repo and run `npm install` and `pip install -r requirements.txt` without issues, you're probably fine. docker adds another layer of complexity and learning curve that might slow you down more than it helps. that said, if one person is on windows, another on mac, and you start hitting weird environment issues, then yeah, containerizing might save you headaches. but i'd wait until you actually hit those problems before adding docker to the mix. focus on a good readme with clear setup instructions and maybe use something like `.env.example` files to handle config. you can always dockerize later if needed

nice execution on the mvp. the hash verification + auto-reveal flow is solid, and the design choices (wax seal cracking) show you're thinking about the experience, not just features. on the free tier question — i'd start with 3 active rooms. here's why: you want free users to feel the constraint just enough that upgrading feels like relief, not punishment. 3 rooms lets someone try real use cases (work predictions, friend bets, personal goals) but they'll hit the ceiling fast if they're actually engaged. 5 might be too comfortable for too long. also, track what kills free accounts — do they churn because they hit the limit, or because they stop using it before they ever get close? that'll tell you if 3 is too restrictive or if engagement is the real problem. one thing i didn't see mentioned — any thoughts on making rooms shareable before they seal? like "hey vote on whether i'll actually ship this by friday" could drive some viral growth if the landing experience is good.