In 2021, it’s hard to find people who prefer calls and real communication with staff to texting messages and making orders online. It’s a large problem for night clubs: guests have to wait for servers, talk to them, and then wait for an order to come. Plus, it’s a difficult task for a club to control cash flows: who paid, and who didn’t.
What if all these tasks were handled with text? Read the case study to know how the Purrweb team managed to develop five apps at once that minimize personal contact.
A little less conversation, a little more action
Lockdown became the word of 2020 and a reason to develop new technologies and mobile apps. In April 2020, when the first wave of Covid-19 began, we got a request from the client — a former professional football player. His idea was to create a system of apps for night clubs that would minimize personal contact and increase the business efficiency.
But lockdown didn’t cancel the eternal problems of clubs: you’re waiting for servers for ages, and when they come, you realize that you need to wait for another worker to order a private dance or a hookah. Plus, I guess, you can imagine how chaotically money flows at night clubs: drunk guests might accidentally overpay, underpay, or refuse to pay at all. Every club needs a clear accounting system to manage money flow.
To cover all these scenarios, we needed to develop 5 (!) apps at once:
- for lap dancer;
- for kitchen workers;
- for servers;
- for guests;
- admin panel to manage everything.
…and the payment system, of course.
So, the guests can use this app to order everything they need and pay for the order without talking to servers. For the staff, it’s a big dashboard that reduces chaos in the club and helps to monitor money flows.
But have you ever tried to simultaneously build 5 apps within 6 months, and then merge them into one environment? Neither had we, but here’s the story.
The only usual thing in the project — technology stack
To develop the apps, we used our usual framework tested in multiple projects — React Native. We decided to follow our regular path: UI/UX design → coding and QA testing → release and landing page describing the whole system. Our project team consisted of:
- a project manager
- 4 developers (1 teamlead, 1 backend and 2 frontend devs)
- a UI/UX designer
Once in two weeks, we presented a demo version to the client and he suggested new ideas for the apps. That was all about the usual things for us.
We were developing all 5 apps concurrently and working on all fronts. That’s how we organized the process: two frontend devs and one backend dev created an app for guests. After building the basic functionality we moved on to creating apps for servers and pole dancers, a web app for the kitchen, and an admin panel. Then one more backend dev joined us to build the admin panel — he was coding specific requests for the kitchen. From that moment we started splitting and the teamlead only worked on the backend.
All systems were interconnected: we couldn’t move forward in the development of one app until other ones weren’t ready for the next step. The QA testing process wasn’t simple either: you can’t test one app independently, because a single feature is spread across multiple apps.
Juggling the apps
The hardest thing was to put the flow of orders together since there were several roles and apps. These are the features that were implemented:
- Monitoring all venues, creating users (admins).
- Adding the staff, food, and drinks for the venue.
- Signing in: inputting name and surname, loading a document photo, loading a selfie (it confirms that a guest is a real person). The app automatically compares the photo on the document with the selfie through Amazon Facial Recognition. After the identification, the app generates a QR-code for receiving the order. The QR-code contains information about all orders and payments of the guest. The feature of age verification for selling alcohol stayed in the backlog.
- If it was a guest’s initiative to order a dance, he/she gets a QR-code after the identification. If it was a lap dancer’s initiative — the guest generates a code, the dancer scans it, dances, and then bills the guest. The dancer decides whether he/she will dance or not and puts a price.
- Getting order details.
- Choosing a venue, managing orders.
- If a dancer is on shift, their card is displayed in the guests’ app.
Usually, we spend 30 minutes on one build but in this case, it’s not one but two apps that require regular updates. It takes a lot of time. Plus, we had two different backend servers: one for staging (testing the builds in TestFlight and Google Play Console) and another one for releasing the app. All together it takes a very long time.
To speed up the process, we connected our repository on Gitlab to the App Center and automated the builds. It cost us 40$ a month but saved 4-5 hours per week.
Miraculous update of the payment system
It turned out to be even harder with payments and taxes. That’s what we agreed on at the beginning: the system takes 4% of every order in a club/restaurant/cafe/bar. The commission is the same for all venues.
Before the release, our client reconsidered the whole payment system and that’s what we got in the end:
- % is different for every venue (4-6% and higher);
- a club charges a 20% margin on dishes ordered by guests;
- taxes: 20% from the system and 10% from a club owner;
- service fee (can’t be charged from lap dancers).
These agreements affected the app’s architecture, so, when the client finally decided on how the payments will work, we needed to rearrange the payments of orders and tips. It changed the database structure and the structure of all projects that display this information.
We needed to do the maths wisely: count how much guests will actually pay and how much the payment system will charge for every transaction.
We had a dozen of video calls with the client to discuss this issue, validate the calculations, and make adjustments.
We decided to implement payment with Stripe in our apps. It easily connected to the web service, however, the React Native mobile app was not the same. There was an open source library tipsi-stripe, but Stripe had rebuilt their API, and by the moment when we started, it was clear that the library was outdated and wouldn’t work for us.
While we were nervously searching for alternatives, it turned out that one enthusiast updated the tipsi-stripe library. And it had everything we needed: card binding, payment intents. We thought it was incredible luck. Although this update helped us to keep within the schedule, now we realize that we would find a solution anyway. We would have created bindings for the native libraries or used web elements: created a web page with stripe-elements and made a webview in the app to look natively.
We have been working on the project for 6 months. Initially, we planned $40.000 but the total budget was $80.000 because the system expanded — some features were critical for the functionality. But even $80.000 is quite cheap for 5 apps with a payment system and an admin panel.
Our system has no equivalent in the market of services for clubs and bars.
One server for one guest
Our client had great plans for the system: he plans to wrap up the environment and offer it to clubs and bars. He wants to get a commission of every check. At the start of the project, he had 3 partner venues located in different states — now they’re already testing his system. We adapted the payments to every state’s tax system and released the app: it’s already available in the App Store and Google Play.
Before the launch we refined a couple of features:
- finished the option to hide a venue — so that admins can remove a club if they don’t work with them anymore.
- made sure that the payment system works right and that money is correctly distributed between accounts.
- worked through the option to connect a particular server to a particular guest — the server scans the guest’s QR-code and binds to them for the night (the server is the first to get the orders from the kitchen).