Planning for the first release

Our first release is planned around the start of the Easter Holidays, which leaves us with two weeks to implement a working scenario. As the time window is short, we try to keep our scenario as small as possible. Therefore, we’ll focus on creating a party, sending and receiving party invites and arranging a time for the party.

Minimal scenario: parties

Our minimal scenario is based on our paper prototype , but with some less important features left out:

  • We ignore the ingredients lists for now. We will allow users to invite any of their friends to a party, we won’t restrict the partners list to those who can contribute to the missing ingredients list.
  • We won’t manage the user’s fridge for now. Since we don’t use the ingredients lists yet, there’s no point in users already adding items to their fridge.
  • We won’t have dishes yet. The selected dish determines the ingredients list, but that is unused in this first release.

The rationale behind this is that we want to focus on getting the party creation and invitation working. If users can’t successfully create a party, then there’s no point in managing their fridge with our app.


The first release is planned for the start of the Easter Holidays, in two weeks from today. We already have a working base application, so we’re already past the bootstrapping process. That means we can focus on the actual user interface design along with the business logic code. We mapped the relevant interface screens to implementation tasks:

  • Choose time slots
  • Choose and invite partners
  • Receive party invitation
  • Choose time arrangement (select one of the agreed time slots)
  • Receive time arrangement (for the other party members)

Since sending and following partner invitations requires quite a bit of help from the backend server, we subdivided that task in GUI and backend subtasks. (Other tasks also rely on the backend, but need less complex communications.)

The Gantt chart below (in Dutch) shows our planning for the coming two weeks. We’ll be working mostly separately and in parallel on these tasks, checking up on each other’s progress along the way and slowly integrating the parts into one activity flow.



We have (what we think is) a fairly minimal scenario which should be sufficient to create and manage a party. This scenario is far from complete, but should give users a good idea of what will be possible with our app when we’ll add in the fridges, ingredients and dishes. Now, it’s just a matter of sticking to the planning and hope we manage to fix the bugs (which are guaranteed to occur) fairly quickly. 😛

We’ll keep you up to date on our progress right here, so stay tuned! 😉



  1. I don’t know if this minimal scenario isn’t too limited. You are just going to be able to invite some people, it isn’t that much related anymore to food (however this was your first idea). I have the feeling you are taking the soul out of your scenario by doing this, I think it would probably be better to only allow one (or even a couple of dishes) on top of this scenario. It would be much more useful to test in my opinion.

    1. We could add the dishes in, but we certainly cannot implement all ingredient-related features in the first release. Fridge managing and fridge matching are both quite heavy and complex, we simply don’t have the time for those.

      Would it be better to already have the list of dishes (as in screens 1-3 of the paper prototype), but without the ingredients list (in screens 5-6)? That way, you can already select a “goal dish” for your party, but the app doesn’t yet assist you in actually reaching that goal.

Comments are closed.