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 nightclubs that would minimize personal contact and increase business efficiency.
But the lockdown didn’t cancel the eternal problems of clubs such as 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 nightclubs: 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 dancers
- 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 monitor money flows.
But have you ever tried to build 5 apps within 6 months simultaneously, and then merge them into one environment? Neither had we, but here’s the story.
The only usual thing in the project — the 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 team lead, 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 building 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 team lead only worked on the backend.
All systems were interconnected. We couldn’t move forward in the development of one app until the other ones were 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:
And this is the scope of work for every role:
1. Monitoring all venues, creating users (admins).
2. Adding the staff, food, and drinks for the venue.
3. 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.
4. 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.
5. Getting order details.
6. Choosing a venue, managing orders.
7. 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 just one but two apps that require regular updates, which 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 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% off 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:
-
- the percentage 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 how the payments would 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 math wisely: count how much guests would actually pay and how much the payment system would charge for every transaction.
We had a dozen 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 was easily connected to the web service, however, the React Native mobile app was not the same. There was an open-source library called tipsi-stripe, but Stripe had rebuilt their API, and by the moment 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 and payment purposes. We thought it was incredible luck. Although this update helped us stay on schedule, we realized 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 look natively.
Double budget
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 the environment up and offer it to clubs and bars. He wants to get a commission for 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. Now, 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 worked right and that money was correctly distributed between accounts.
- worked through the option to connect a particular server to a specific 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).
