Project idea

    To create a mobile app

    The service already had a website and a mobile version of it where users could order meal kits for a week. The company regularly collects user feedback and performs user analysis. The results revealed that most of the customers prefer making orders on a mobile device. Moreover, in the feedback they gave, customers particularly asked the client for a mobile app. Besides, its competitors already had apps. 

    With the data in hand, the company realized that a mobile app is essential for its business. And to build one, it came to Surf.


    Here’s what we had to do:

    • Create a user-friendly mobile app that would at least be as functional as the website.
    • Implement the app on a tight budget and schedule.
    • Add a recipe section where users can access the recipes at any time, thuswise reducing paper use and making the project more environmentally friendly.

    What we made

    We provided the delivery service with a functional and minimalistic mobile app. The client liked our design and home screen layout so much, they were also implemented on the website. Not only did the app attract a large number of mobile website users, but it also lured some new customers. 

    In the app, customers can pick meals from a number of price ranges and in accordance with their personal preferences. Meals can be delivered to several addresses, e.g. users can order food for themselves and their parents. Payment with bonus points and promo codes is also available at checkout. 

    The new section that the website never had and that we added to the app was recipes. Once users receive the meal kits, in this section appear the recipes of the meals they need to cook. All recipes are scheduled in accordance with the actual expiry dates of the ingredients delivered. 

    The app was built using the Flutter cross-platform framework, which saved our client about 30% of the cost of native development. 

    How we made it

    Detailed analytics and the homework

    The Client appeared to be pretty meticulous in its preparations for mobile app development. It already had a finished concept, technical specifications, and a brand book. In addition to that, the company pays great attention to user analytics and regularly collects customer feedback. At the start of this project, it handed us a doorstop of data: information about their company, its values and policies, analytics covering 2 years since the project onset, and all customer reviews organized in tables.

    However, in the process of development, website logic turned out to be unsuitable for a mobile app. Therefore, we suggested our own idea. The client liked it so much, they changed the mobile version of the website in accordance with the app after the project was finished.

    Prototype and design

    The company came to us with their own prototype. Unfortunately, it didn’t reflect all the necessary features and was built using a software product unsuitable for building mobile app prototypes. Therefore, first off, we audited the prototype, discussed all controversial points with the Client, and based on user analytics suggested our solution for each feature.  

    The resulting ideas were then transferred into Figma (a software product specifically built for interface design and prototyping) and then considerably adjusted and modified. As a result, the Client had a clickable prototype showing how particular features work and what this or that section of the app would eventually look like.

    Universal logic

    The Client has a flexible and agile company. It’s always analyzing statistics and reviews, improving its service, trying out new solutions, and testing hypotheses: changing the menu, the loyalty system, and the structure of its catalog. Therefore, one of their requests was to implement a mobile app the company can adjust on its own. 

    In order to do that, at the stage of project development we made allowances for flexible logic, not planting things in the app if they could later be altered. This enables our client to adjust the app without our help. All changes are made on the back end: once a week they change the menu, add new meals and recipes, change the content in the breakfast\dinner\other sections, and add a new range of products. Meanwhile, the app simply receives the data. The client found it convenient: it can manage the contents of the app and introduce any necessary adjustments on its own.

    Home screen

    According to the analytics, the home screen is where the users spend most of their time. Due to that, we paid maximum attention to its code and design. 

    We kept all the crucial elements the Client needed — the side menu and large pictures of meals at the top of the screen. However, we used user analytics to significantly modify the logic. Customers didn’t like that the home screen only showed the main meals\dinners. To see the available soups and desserts, users had to add a minimum of 3 dinners to their carts. That was confusing and made users waste their time on orders they might not like in the end, because they’ll later find out that the menu doesn’t have the soup or dessert they want. Besides, it’s hard to decide whether you want to order or not when you can’t see the whole list of items available.

    We changed this logic in the app — users can now look through the whole selection of meals and open the cart even if it contains less than 3 dinners. The home screen of the app shows meals from all categories. In addition to that, we reconsidered the names of the main sections in the catalog — the website only had “Main course” and “Other”. We suggested changing the “Main course” into “Dinner” — a short section name looks better on a small mobile screen. Meanwhile, the “Other” section was split into “Soup”, “Breakfast”, and “Other” — this way we’re saving our users time by letting them know straight away what this or that section contains. 

    To separate dinners from everything else on the home screen, we suggested changing the visual concept. Dinners are now shown on large cards while the rest of the meals have smaller cards. The Client loved this idea and later on implemented it on their website as well. 

    Apart from that, meals are also divided into various price tiers — premium, standard, and economy. This aspect is also reflected in the way the cards look. Premium meal cards are a different shape and have an extra graphic element on them. 

    The company can also add extra categories to the app, like Valentine’s day meals or grilled meals they add in summer. Such meal kits are marked with a respective icon and a tag. 

    We had to give up on the idea of displaying the logo on the home screen: every inch of a small mobile screen is too precious and it makes much more sense to fill this space with as many goods as possible. 


    The information on the flypage of a meal helps customers make the right choice. Flypages in the app have all the necessary information:

    • nutrition value and serving size,
    • difficulty and cooking time,
    • a list of ingredients,
    • kitchenware needed,
    • the term within which the meal must be prepared.

    At the same time, the flypage shouldn’t be overloaded with information. It’s also important that users see the ‘Add to cart’ button straight away.  

    In addition to that, we suggested providing the mobile app users with the ability to switch between meal flypages by tapping on the right and left sides of the screen. This way users can look through several meals without having to go back to the main catalog.


    The service gives its customers a chance to cook restaurant-quality meals at home. Recipes are their know-how. However, they weren’t available on the website. Customers got recipe printouts with each order they made. That was neither handy nor environmentally friendly. 

    Therefore, the company decided to transfer the recipes into the app, where they are divided into this week’s recipes and the rest — an archive of all previously received recipes. The archive also has a search feature. 

    New recipes appear in the app as soon as customers get their order. Each recipe states the deadlines based on the actual expiry dates of the produce delivered. The catalog of this week’s recipes has them sorted in accordance with the deadlines. This way the service helps users understand which meals should be made first before the produce goes off. 

    After the meal is ready, users can press the “Done” button, and the recipe goes into the “All” section. If users don’t press the button, the recipe is removed from the scheduled recipes in 2 weeks. 

    Making an order

    Making an order is the key procedure in a food delivery app. When building a mobile app, it’s important to keep in mind all the possible use cases related to that. 

    The service had its own ordering logic: users could only order soup or dessert after they made a minimum order of 3 dinners. This logic isn’t obvious to new users, that’s why in the mobile app we implemented a great number of prompts to simplify the ordering process. 

    If their cart doesn’t have enough items for a minimum order, users see how many meals they need to add.

    If they have enough meals for a minimum order but not enough for a discount, users are also shown a prompt. All discounts are applied to orders automatically.

    Once they open the cart, users see an indicator that also shows them how many meals they need to add to make an order. As they add more meals, the indicator gets a cooler shade of blue.

    Users can’t make an order unless they add a minimal number of meals to their cart. Meanwhile, the “Make an order” button is active but reads “Add meals” and takes users back to the main menu. Once the minimum order is put together, the “Make an order” button gets activated.

    When users pick a delivery date and time, it’s crucial to give them a choice of several dates and time slots.

    The app supports several payment methods: by card, in cash upon receipt, and Apple or Google Pay. In addition to that, users can cover the cost of their orders with bonus points or activate a promo code. 

    The service also enables users to order deliveries for someone else, say, their parents. However, in this case, the only payment method available is an advance online payment.

    One of the trickiest cases we had to implement in the app was when users order kits in advance, so that they only arrive next week. While the logic of orders for the current week is pretty simple — users pay for their order and have it delivered the same day or the day after — advanced order logic isn’t as straightforward. On the one hand, people don’t want to pay for such orders too far in advance. The service, on the other hand, needs some kind of a guarantee that the order will eventually get paid for. To implement this case we had to come up with a complex logic. 

    This is what it looks like in the app. Users make advance orders and, to guarantee their commitment, enter their payment card details at the time the order is made. This order is then added to the order base with the rest of the orders and assigned a separate status. Once the time comes, the backend sends a request to charge payment for this order. This way the service only charges users at the start of the week in question.  

    Moreover, Apple or Google Pay can’t be used to pay for the next week’s delivery, since they charge the money instantly. Hence, we had to hide these buttons when we dealt with next week’s deliveries. 

    Whenever a customer orders the second delivery for the same week, the app asks them if they want to order more food for themselves or order delivery for someone else. This helps avoid situations when orders are delivered to the wrong address.

    User account

    We pared the user account details down compared to the ones on the website to make them easier to fill out on a mobile device. We broke all the information down into 3 sections: basics, extra information, and favorite meals. 

    We also made it possible for users to add several addresses, thus making the process of ordering meals quicker: users can enter all possible delivery addresses only once and then simply pick the one they need. The main address is always suggested automatically.

    There’s also a “Favorite meals” section where users can add up to 5 meals they like. The service will take them into account when putting together a menu. In addition to that, favorite meals are what the service uses to base its personalized promo offers and discounts on.

    Loyalty program

    A loyalty program is a must-have for a modern food tech service. It boosts customer loyalty and motivates them to come back to you over and over again. 

    Our Client has a complex loyalty program. What we mean by that is they give their customers presents for a certain number of orders made. What’s more, each order comes with a complimentary gift — a pack of their own cookies. 

    Whenever users invite their friends into the app or face a service error, they are given bonus points. 

    In the mobile app, users can pay for their orders in bonus points or pick a gift.  


    Our users really appreciated how friendly the design of our app is. It instantly affected the conversion of visits into purchases and retention rates. Back when our project was drafted, Surf’s designer made his own suggestions as to the changes we could make in the initial prototypes giving sensible reasoning and speaking from his personal experience. As a result, the design of our app turned out to be so successful we used it to redesign the mobile version of our website.

    Head of Marketing

    Contact us
    Let’s discuss your project together
    CEO photo white

    Vladi Makeew

    CEO of Surf
    Drop a file here or click to upload
      Hidden span