Back

How we developed an application for smart fridges in 6 weeks. Vendify case study

How to create a product that users will definitely fall in love with? Take a thing that everybody uses and make it 10 times simpler. That’s exactly what our clients did — they decided to create a modern equivalent to vending machines with convenient payments and simplified work principles. My name is Kristina Spiridonova, I’m an account manager at Purrweb and I’ll tell you how we helped the client achieve the goal through mobile app development.

Reading time: 8 minutes

Table of contents

    In November 2020 clients from Latvia requested us to develop an app. Maksim — experienced backend developer, and Aivis — entrepreneur who finances the project. The idea was simple: sell products via smart fridges located in offices and hotels. The product is healthy and fresh food that customers can buy and microwave or eat on the run. For our client, it’s also an opportunity to partner with large food suppliers.

    Traditional vending machines frighten people, look scary and not cool. It’s inconvenient to pay for products, you can’t check the expiration date before buying and can’t return the products. All these things don’t look credible. The client’s fridges are made for people — you open the door, take any product, touch it, smell it, check the expiration date, put it back, or take it with you. To make the payment process convenient, the clients decided to create a mobile app.

    There were no similar apps on the market, so the clients wanted to create an MVP as fast as possible, validate it, and move forward to the European market. They’ve been constructing the fridges themselves, the backend part of the app was also on their shoulders. What they needed was a proper UI/UX design and development of the frontend part. There were three reasons to choose Purrweb:

    • The clients liked our design concepts on Dribbble
    • Our specialization is React Native, which perfectly fits for developing a mobile app MVP
    • We already had experience with IoT development — Energo app

    The terms suited both sides, and we started the development off. We gathered a team of a project manager, UI/UX designer, and two frontend developers.

    Interface that matches the fridge

    We started the project as usual, with design. The clients had a corporate identity and ready-made brand book — it simplified our work a lot since we didn’t need to create a mood board and design concepts.

    We were provided with a small but well-prepared brand book — with logotype, main and accent colors, fonts

    There aren’t many screens in the app: the clients came to us with thought-out app logic and even sent us self-made wireframes. We expected it all to go like a dream — we only needed to design the screens, create the layout and connect everything to the finished backend.

    User flow in the app:

    • user scans QR-code on a fridge
    • smartphone opens the page of Vendify app in an app store or the app right away (if it’s already installed)
    • user links bank card
    • sees the fridge contents and sends a request to unlock the door
    • fridge door opens
    • user takes the products
    • closes the fridge door
    • fridge sends the app information about the chosen products
    • payment proceeds automatically

    We designed the interface concept in a dark theme — to match the fridge. Pictures of products that we used on the screens are actual products that users can buy from the Vendify fridges. The concept impressed our client.

    Julia Vakulenko,

    Further, we had difficulties working on the interface: changed paddings, moved pixels, redesigned buttons. Edits were going on and on and on. Working in mode ‘change it’ —> ‘we changed’ —> ‘we don’t like it, undo the changes’ is inconvenient.

    Julia Vakulenko, 
    lead UI/UX designer at Purrweb

    To solve the problem and eventually finalize the design, we decided to connect the designer with the client. Usually, we avoid involving creative people in the process of communication but in this case, it was reasonable. We agreed on all changes in real-time, further the work went without any helter-skelter.

    Onboarding

    Initially, the clients wanted to make illustrations for onboarding but we then changed their minds in favor of a simple list on one screen. Why? Because it’s MVP and it’s better to be budget conscious.

    The clients are meticulous but open-minded. Thanks to that we were able to design a concise onboarding without extra details.

    QR code

    One of our design references was Bolt — an app for renting scooters. The client really liked their QR code screen and wanted us to make something very similar. The point is, that the service works only in Europe so we couldn’t access this exact screen. We designed the QR code screen with a blurred background, of course, it didn’t look like the Bolt’s at all. During the design demonstration, the client specified that the background must be darkened, not blurred. We found an article with a screenshot of that screen and met the client’s request.

    Previous version of the QR code screen and current one with the darkened background

    Sign in

    The app doesn’t require users to sign in — just link the bank card and go. It was done on purpose to not scare users away and not create obstacles on their way to the target action (buying a product). But how will the company collect information about users and send them messages about special offers? In the future, we plan to allow users to add their phone number and email address. For example, to get a discount on the next purchase. Now the sign-in screen looks like that:

    Users can link a card only by entering the full details. After the release, we plan to implement Apple Pay and Google Pay.

    Illustrations and animations

    When the fridge door is unlocked, we start a timer — during this time users can choose the products. If the time is out and a user didn’t take anything, the app returns to the QR code screen. We decided to add animation with a hand opening the fridge, this way users won’t get confused and will know what to do. The client chose the linear style, we made an illustration, added Vendify’s brand colors, and animated it. That’s how it turned out:

    The animation makes the app unique and demonstrates how to use it

    Familiar scenario and technology stack

    Our clients chose the tech stack for Vendify themselves. They had Ruby on Rails for the backend, we had React Native for the frontend. Maksim already wrote the API through which the fridges were supposed to ‘communicate’ with the backend. Our task sounded like ‘create a client for the backend so that it would communicate with the hardware and the backend’. In fact, we needed to develop the frontend part of the app using React Native, connect Stripe for payments, and create deep links (links that lead users to the specific screen of the mobile app) — the clients wanted users to scan the QR code right from the smartphone camera.

    The scenario was super clear: React Native development, Stripe integration — we did it all a hundred times. IoT development wasn’t something new for us too, we developed a similar app — Energo. It had almost the same flow: scanned QR-code, opened-took-closed, money charged. Moreover, we created Energo from scratch, developed both the backend and the frontend, and integrated it with the hardware. So, Vendify seemed as simple as possible.

    Problems with the library and the hardware

    We wrote the back and front in parallel — discussed the workflow and technical decisions with Maksim in Slack or Zoom. The first problems started with Stripe. The thing is that it integrates well only with web applications and native iOS and Android apps, while an official React Native library for Stripe didn’t exist back then.

    There are 2 ways to integrate Stripe with a React Native app.

    • Use iOS / Android SDK by Stripe
    • Use a third-party library tipsi-stripe

    In the first case, we would need to create our own library, which is time-consuming and doesn’t make much sense. We decided to choose the second option and took a ready-made solution: tipsi-stripe. Though no one knows how exactly it works and who supports it, there was no other way for us.

    SCA support

    Stripe recommends using their payment form built specifically for iOS and Android. Why it’s important: firstly, it validates bank cards, secondly, it supports SCA — card authentication required for most online payments in Europe. It can be customized to fit the design, while with a custom form, we could have had problems.

    Of course, we wanted to use Stripe’s form. But then it turned out that tipsi-stripe doesn’t support native fields for payment cards so we had to design our own form and get the card details with it. We put off SCA support until the tipsi-stripe updates or the official RN library appears.

    Push notifications

    Push notifications are vital for the app — if a user doesn’t allow notifications, they won’t be able to use the app. Same if notifications don’t show up for some reason. There were 2 questions:

    1. What to use — native push notifications or Amazon SQS
    2. How to get a user’s permission

    Amazon SQS only allows to send background push notifications, we wouldn’t be able to send them to the notification bar. It means that if a user closes the app, they won’t receive any notifications. Native push notifications looked like a more reliable solution but Maksim wasn’t sure about them. He was afraid that some percent of notifications would get lost or delivered late, which would be very unpleasant. We discussed everything and came to the conclusion that with SQS users will be confused — decided not to overcomplicate and use native push notifications. Plus, since we work with hardware, notifications can also be lost if a fridge breaks down. To avoid that, we made additional regular requests to the backend to check the current state of fridges.

    We handled the technical part, then we needed to get the users’ permissions. You can request permission right away but it doesn’t guarantee that a user will allow anything — what is the value of notifications? We decided to inform users that we will ask for permissions and the app won’t work without them. Together with the client, we thought that it would more likely convince users. We’ll find out if our theory is right after the release.

    We designed additional screens that inform users

    Preventing thefts

    The system that tracks products in fridges is implemented in the backend — every product has an RFID tag on it, it allows the backend to know which products are in the fridge and which were taken out. So, theoretically, no one can steal anything from a Vendify fridge: if a person closed the fridge door and didn’t return products, the backend would know about it and charge money. It will be a usual purchase. But what if the door breaks or someone braces it or the fridge shuts down? We needed to consider all these options.

    If the fridge works normally, it will inform the backend about the door_locked event, and the backend will ask the fridge for a list of products. We couldn’t finish the purchase with an opened door, because then the fridge wouldn’t understand which products were taken. To solve the problem, we added a 300-second timer — when a user opens the door, they can choose products during this period. When the time is out, we finish the purchase and the backend asks the fridge which products are taken.

    How’s the project doing now?

    The app’s not released yet — the clients don’t hurry because they decided to change their business model a little. Now they negotiate with partners and slowly develop the product themselves. Our work was done by January — we met the deadlines and finished the MVP in 6 weeks. The clients are happy =)

    ‘The result is great, we liked how the team worked on the design as well as the solutions they offered. The work process was flexible: we could complete tasks in either common or unusual way. For instance, we met online to discuss and make changes on the fly.’ — Aivis Ruza, the client.

    Management
    • Anton Kiryukhin
    • Georgy Putilov
    Design
    • Julia Vakulenko
    Development
    • Andrey Ivanov
    • Gregory Sharapov
    QA testing
    • Elena Rusakova
    Editor
    • Anastasia Khmelevskaya
    Designer
    • Anastasia Miklashevich