Cronum Gastro Pro — Case study

Errortech
Errortech
Published in
4 min readOct 6, 2022

--

Requirements

Build a fully managed CMS platform that supports restaurants in their day-to-day operations. Here are the base requirements/features that are outlined for the project by our clients.

  • Restaurant customers should be able to scan a QR code to get the menu of the restaurants in a web application.
  • If the customer of the restaurant is away from a set distance they cannot use the web application.
  • As soon as the customer places the order it should be notified to the kitchen and only after the kitchen completes cooking the food, it should be notified to the waiter of the restaurant.
  • The restaurant owner should be able to set profiles, and also should have an updated analytics overview of the daily business. He should be able to track table performance, average order time is taken for the individual product to cook, the number of items a product is ordered to find the most popular items, server performance analytics, and many more.
  • The restaurant also has an option for keeping pick-up ordering open, customers can use the web app to order items and pick them up, this functionality is fully dynamic and mainly depends on the restaurant owner.

Planning

Our client explicitly told us to use flutter and the backend was our choice.

Design: The client gave us some references for the designs he liked and a color pallet that we have to use to communicate his brand story. We worked on both the web, android and IOS applications.

Frontend: There are 2 flutter projects to work on, a customer-facing web app built on flutter web, and an Android and IOS admin app for restaurant owners and workers made using flutter.

Backend: Firebase for FCM Notifications, AWS S3 instance for storage and analytics. The analytics data is not based in real time but only loaded when the user specifically requests for data when he/she in the analytics page. The data is updated in real-time. In a nutshell the write operations are based in real time but read operations for analytics are dynamically loaded. We are using Node JS for backend.

Other: All the apps need localization support for English and German language. We were also required to setup geo-fencing to prevent the users from ordering if they are too-far from the restaurants.

Building

For a project of this magnitude it is imperative we need to build v1.0 of the app and release the apps in beta as soon as possible. It takes anywhere between a week to 3 months for the apps to get approval in Appstore and Playstore.

V1.0 beta

Before building the web application, we tasked our designer to build the android and IOS applications. These applications have the same design and deoesn’t have platform specific designs.

For V1.0 we decided to only release one feature that is receiving the orders, the orders are manually uploaded in our database, and any user can sign up for the application using google/apple sign in.

It took us a month for getting the applications ready and another week for uploading them to playstore. We soon hit a roadblock for uploading the apps to appstore though and they suggested design changes and functionality issues. The process of re-applying after making necessary changes took a month to get resolved.

By the time the apps are live on both appstore and playstore we are ready for the webapp design, uploading the apps to appstore and playstore gave our clients an opportunity to showcase the development progress to their end customers.

The v1.0 of the web app application doesn’t have geo-fencing, analytics. But they do have complete ordering functionality. The ordering functionality is also categorized by table numbers, and the waiters can get assigned to their respective tables i.e a particular waiter would only serve the tables he/she get assigned to.

V1.2 New Feature Request

During the development timeline, we were tasked to develop a time-critical feature due to government mandate in Germany. All restaurants must be able to keep track of all the users that visited the restaurant. This required changes in both the web app and the admin app as well.

Users who didn’t fill in the details should be marked as anonymous and the admin app should be notified as well, the users who did fill in the details will have the option to store their details and the form gets auto-filled if they visit any of the partner restaurents.

In the admin app we were tasked to rebuild a new page that has all the customer data including entry and exit time. The exit time is calculated when the user requests for the bill and pays it, that the waiter marks as completed.

We completed and deployed the feature in under-a-week, the admin panel users are required to upload the update the app.

--

--