Addicted to building tools that don't exist yet... making my (and hopefully someone else's) life easier!
I build serverless web-apps, IT admin scripts, and I even do some VO work!
I think option 3 because theres so many variables to consider due to current nature of the word “gender” (maybe more here in the US) but also other “trust factors”
I have a similar prototype for a ‘members only’ app, wherein the members are all invite only and referral based. There is a publicized rule where if the conduct of a member deems dismissal, their referrer is also dismissed. The only way to rejoin is of course from an existing member. The ‘referral tree’ is an ever changing data schema. The MVP uses firebase for sms 2-factor login.
I think option 3 because theres so many variables to consider due to current nature of the word “gender” (maybe more here in the US) but also other “trust factors”
I have a similar prototype for a ‘members only’ app, wherein the members are all invite only and referral based. There is a publicized rule where if the conduct of a member deems dismissal, their referrer is also dismissed. The only way to rejoin is of course from an existing member. The ‘referral tree’ is an ever changing data schema. The MVP uses firebase for sms 2-factor login.
This is very interesting actually. The referrer dismissal will make sure existing users won't break the system.
Thanks for the suggestion.