Home

Problem

It's become increasingly difficult to organize group finances where there are multiple groups of roommates. The frustration in splitting costs and keeping track of who owes who how much led to the creation of this application.

Design

Each meal has:

• a list of diners who dined at that meal has_and_belongs_to_many
• a date
• a list of ingredients used in that meal has_and_belongs_to_many
• [a meal type]
• [a chef]

Each ingredient has:

• an associated diner who bought the ingredient belongs_to
• a list of meals that the ingredient was used in belongs_to_many
• a cost
• a name
• [date] in the case that multiple copies of the same ingredient is bought

Each diner has:

• a name
• a list of payments an array of payments…thoughts?
• a list of associated ingredients has_many
• a list of associated meals has_and_belongs_to_many

Each payment:

• cost owed
• to_whom diner object
• from_whom diner object

Page Flow + User Experience

1a. User is directed to login (aka the home) page if not signed in regardless of what URL they want to go to. 1b. User has ability to sign up for an account from the login (home) page. 2. After successful signin/signup, we direct them to a page where they can either check-in to meals (a) add ingredients (b) or sign into a meal as a chef (c). 3a. User then has ability to select multiple dates to sign into meals (eventually we should extend it to lunch as well, but dinner for now since everybody has lunch covered) 3b. User should have the ability to enter multiple ingredients from a single page (Excel style). The ingredient automatically defaults to be bought by that particular user. 3c. The chef has the ability to choose what ingredients were used in that meal (and if a particular ingredient is finished or not). 4. Once we get the basic functiaonlity of calculating costs, we need to implement Venmo's API so people can sign into and pay with their account.

Side Stories: aka cool features that our friends came up with

• A “guest” account when we have dinner guests - they should make a guest account that automatically opts out of every date except for the one they signed up on. Of course this date is changable, but the idea is we default them to opt out of every meal If they happen to sign in to their “guest” account again, then we want them to be able to add to the meals that they’ve guested at previously.
• Stats to keep track of monthly costs associated with food in the community (i.e. how much each person cooks, top buyers, top ingredients...)
• Interesting global hash method suggested by @david. Essentially, we only keep track of one number per relationship. This way there’s no redundant costs if person A owes B $4 and B owes A $2. There’d just be a simple +$2 costs associated with the relation A<->B. This of course means that we’d have to calculate costs for everyone whenever we update the costs, and thus update the global array, instead of the current approach where updating the costs for one diner would be independent of what happens for other diners.