FLAVR - responsive web application for homemade food delivery

But cooks are not the only people that profit from created app - it also allows users to eat a good-quality meal created by someone from their neighborhood.

Timeline

We started our work with conceptual workshops based on design thinking [you can read more about the design thinking HERE]. The workshop was divided into two days:

• DAY 1 - by using the design thinking method we learned as much as possible about the product and understood its vision and main goal. It also allowed our Customers to think through their needs and consider whether there are some elements that can be improved;

• DAY 2 - once we knew everything about the product and what we will have to work on for the next couple of months, then we could move to the second phase of the workshop - discussing used technology, presenting our proposals for the initial solutions and planning first work sprints.

Workshops conducted in such a way ensure that clients are going to be satisfied with the vision of the project that we present. After gaining a factual knowledge and meticulous planning of work, there was nothing else to do than begin!

1. Workshops (March 9 - 11) - as I mentioned above, the project started with a workshop, which left us with a plan of work for upcoming sprints;
2. Start (March 21) - it was an exact the day we started working on the project. We created an environment, did some research on the project and focused on the development of first functionalities. One of the requirements was to fulfill a very tight deadline for MVP version of an app (end of April, which then, per client’s request, was moved to the half of May);
3. Meeting with client (April 28-29) - at the end of April our client wanted us to conduct a meeting, during which we were able to talk through some details before releasing an MVP version of an app;
4. MVP version (May 15) - exactly on March 15 we released an MVP version of an app (technically it was a Sunday, but we were able to work for our Client's request);
5. Final product (July 15) - we finished our work on Flavr.be and handed out the documentation. Our code was verified and then approved by a professor for a Belgian university - those kinds of praises we like best!

The course of the project

Since the beginning, the project was conducted in Scrum, what allowed us to quickly react to encountered problems. Each sprint was a weekly interaction, after which we were delivering a finished product to Product Owner. Among difficulties that we had to face at this phase were:

• deadline - which was extremely strict. At the beginning, it was only one developer that worked on the project, but then two of his teammates joined in. We quickly realized that even three programmers couldn’t finish their tasks on time, so another person worked on Responsive Web Design;
• pushing changes to the production server - despite the fact that the sprint was planned, we couldn’t wait with making some amendments until it ended, so we uploaded them during the sprint (for the sake of the product);
• frequent changes in the project - deadline and budget were established, but we couldn’t forget about the changes that we received after the release of the application. We had to carefully evaluate the scope of work to avoid making any mistakes (at to work within a deadline and a budget);
• server - even though we were not supposed to deal with server-related issues, we found ourselves needed when it comes to support and configuration. But I will touch more on that matter later;

As in every Scrum project, we identified three basic roles:

• Product Owner - in this project it was our client. He made decisions, was available to talk everything through as well as confident in their expectation of the team - proper qualities of a great PO. In addition to that, as it turned out he also is a graphic designer and supplied us with the missing views;

• Scrum Master/Project Manager - we chose one person to be a Scrum Master, who takes care of the organization of the whole team. He organized all the necessary meetings and saw to it that the project was carried out from start to finish in Scrum;
• Team - four experienced programmers and one QA Specialist - the perfect team to prove such project as Flavr on time and in accordance with all requirements.

Technologies we used

One of the requirements of our client was to develop the application with the use of Mean stack. Our client plans to develop their product "in-house" - because of the popularity of these technologies in Belgium they won’t have problems with finding specialists that will understand their code in the future.

The mean stack is a collection of the JavaScript frameworks that allow development of comprehensive applications. It consists of four main technologies:

• MongoDB - database used in Mean stack;
• Express - a Node.js framework that provides many ready-made solutions that help in application development;
• Angularjs - it’s the Google-supported framework which helps in supporting the creation of an app. Its main task is to implementation the MVC (Model-View-Controller);
• Node.js - a Javascript runtime environment for creating scalable applications on an open-source license.

To build the interface of Flavr we primarily used Angular Material Design, which provided us with a set of ready-made components to create a whole comprehensive application. You can find more information about it on the official website of Google Material Design.

Another technology we used that’s worth mentioning is WebSocket. In this project we used it to create notifications, for instance, the one's user receive after the purchase. WebSocket technology allows all plugged actions to happen in real time. Otherwise, users would receive notification only after they refresh the page.

When it comes to payments gateway, we used Adyen. Implementation of payments was hassle-free and, if we had any questions, we could always ask their support team for help. To assure that users could buy meals in as many different ways as possible we implemented such methods as Visa, Mastercard, and Maestro/MisterCash.

Server

Our project was placed on an AWS server (Amazon Web Services). One of the assumptions of the project was that the server should be scalable so that it won’t cause any problems during “rush hours”. AWS offers a great flexibility and is able to handle sudden spikes in the amount of users, which are especially visible during marketing campaigns. With this solution, we were also able to save money that might’ve been spent if we used anything else. We didn’t have to buy a dedicated machine which would help with spikes in traffic scheduled for a particular day, but would also be a waste of resources on a daily basis. AWS is a solution that is simply cost-effective.

Summary

Flavr is one of those projects that we will fondly look back at. We were given the opportunity to work on an innovative idea of and using technologies that we really like. While delivering the project to our client we received many praises of our code, which has been tested by the developer of our client. All our work has been appropriately documented, thanks to what our customers can now work on his application the way he wanted to since the beginning - in-house. To sum up the whole project in one sentence: it was one of the best projects in which we had a chance to work! We wish our customer the further successful development of the application - you can check out the results of our work at the Flavr.be