Right now members of a plan are stored as an array in the plan document. This causes multiple issues including but not limited to, difficulty editing collection, inefficient getting user information, etc. Although there may be an argument on each side, it seems to be a more natural use of the firestore architecture to store the members in a subcollection. This means adjusting anything in the plan making algorithm to get members from the subcollection.

Right now the creation of the friendsPlans array is an ugly process of using a map function to create a multidimensional array where the plans are embedded inside of an array of friends which has to be unpacked. I believe there is potential to clean this up significantly by using the reduce method instead of map.

See if the functions folder it necessary. If possible I think it's better to have an src folder and have all extraneous files be above that, but firebase may not allow it.

Implement automatic merges with loners and pairs. Should successfully write to all plan subcollections uniformly. If nothing past this was implemented, the algorithm should still work somewhat up to groups of 3 which is a definite accomplishment. This is a barebones solution.

Github is warning that there is a security vulnerability. Research what that vulnerability is and work to resolve it.

It's vital that users are able to block others in order to insure everyone is able to have an experience free from anxiety while using the app. Assuming the interface insures that blocking lists are stored under each user, a check to insure that no one is put in a plan with someone on their block list must be implemented.