Vibe coding an at-home drink ordering app

"K. Catfé" is a progressive web app for home baristas that allows guests to place coffee orders. Have guests over in the evening? Switch to bar mode to let them order cocktails.

As a "customer," you are able to:

view the menu
place and cancel an order
get notified when your order is ready
get notified when your order is canceled

As a barista/bartender, you are able to:

get notified when a customer places an order
view, ready, and cancel customer orders
switch between cafe and bar modes
view/add/edit drinks, including options and customizations, recipes, and instructions

Tools used:

Figma Design
Builder.io
Lovable
Supabase
Fireside Cloud Messaging
Gemini and ChatGPT
Good ol'fashioned Google Search

Context*

I really like my coffee. So does my husband. Because we need some form of caffeine at least once a day, we have a coffee setup at home that allows us to make coffee in three ways: espresso based, hot pour overs, and iced pour overs (yes, they're different brew methods).

My husband is a busy man so there are times when he's stuck in meetings and will send me a message asking if I can be barista for the day. Then we'll have a distracted back-and-forth on which coffee he wants and at what size, what milk, etc, and I'll ask him to remind me what the weight is for the beans for that specific coffee. Meanwhile, someone's asking him his opinion on something in his meeting and it's a lose-lose-lose for everyone.

I know what you're thinking: "Can't he just write you a note?" Go ahead, ask him to write you something. He'll say, "Write? Like with a pen and paper? It's 2025."

He's right, it is 2025. There's a boom of AI-coded apps and I had a goal as a product designer to familiarize myself with them. Two birds and one stone later, I decided to make an app to solve our very first-world problem.

*tl;dr - We like coffee, we're extra, and we're nerds - that's why this app exists.

Getting Started

In 2021, with our growing coffee setup and my growing design career, my husband asked me to make a collection of coffee cards that we could print out and put into a recipe book.

While the recipe book never came to fruition, it was the inspiration for the coffee ordering app.

I started with the menu design and provided it to Builder.io to implement the rest of the app with the following prompt:

I want to build a web app that has two different uers: * Baristas * Customers Users needs for baristas * Turn on/off ordering * See what customers are ordering and what their names are * Decline orders * See recipes/instructions for different orders User needs for customers: * Set their name * Browse the menu * Select coffee/matcha * Specify options for their drink * See their order status * Be notified that their order is ready

While what it produced had created the UX for both the "product detail pages" and the "barista dashboard," Builder.io wasn't exactly equipped to actually handle the design, interactions, and overall completeness that I was hoping to achieve. That was when I learned that Builder.io probably wasn't the tool I needed in order to launch a working, viable app.

Not to say that it wasn't a fruitful endeavor, as I was able to take the PDPs and dashboard and add them to my original designs.

Designs for the dashboard (left) and PDP (right) inspired by Builder.io

Initial drink customization designs were as a slide up drawer (left) but after analysis of other drink ordering apps, single select buttons for customizations were designed (right)

With those additional screens, I next tried Figma Make with the same prompt. Similarly to Builder.io, what Figma Make produced wasn't creating the end-to-end process that I had designed, and worse than Builder.io, wasn't translating my designs well at all. Ultimately, my goal was to have my AI tool help me, not for me to spend the extra time to tweak my designs in order for Figma Make to implement "properly."

I decided to use Lovable.dev because it promised to implement similarly to Builder.io as well as build a full stack app, which is exactly what I needed.

Using Lovable.dev for developing the UI

Directly from Figma, I exported the designs and it created the screens with the expected behavior interactions. Subsequently, through trial and error, each message would form the user interface of the app.

This is a coffee ordering app. This is the barista's dashboard where the barista can view recipes of drinks, turn the ordering ability on and off, view current orders, and mark them as ready. When tapping the three dot menu of each order, the recipe for the specific order will be shown in a slide up drawer along with the user's specifications for their order. The three dot menu in the slide up drawer should show options to cancel the order.

Early screens of what Lovable.dev produced given Figma designs and prompting

Once satisfied with the UI, I wanted to start designing the functionality.

The start of the work I wouldn't be able to do myself without a lot of help, at least not for a long while

I was prompted to connect my project with Supabase that would then allow me to store and reference recipes, orders and order statuses, ordering modes, and barista login information.

Regarding the Bar Mode*

While grabbing dinner from our favorite Japanese take-out spot, my husband noticed they were selling Yuzu syrup. He said, "This would go perfect in a Highball." I told him, "Oooo, another one for your repertoire."

He and I probably had the same flashbacks of our holiday get-togethers, where he's playing bartender and people are asking for different drinks for him to make. We immediately came to the same conclusion: I have to do the same thing as the coffee app but for cocktails.

It's not even a question: I'm building it into the coffee app, not dissimilar to how a cafe can run in the day and is home to a speakeasy at night (lookin' at you, Asa Cafe/Bar Kamon in San Diego).

From the barista menu, I want to tap/click a moon icon and that changes the system from a coffee mode to a bar mode!
This will:
change the color schemes to a dark mode, with blues instead of browns
change the app name from “K. Catfé” to “Bar Kelrin”
unhide the “Cocktail” category, which should be hidden when in coffee mode.
When in bar mode, the moon icon will change to a sun icon and when tapping/clicking the sun, it will revert back to bar mode.

*tl;dr - We like to drink cocktails, too, so this app also has a bar mode.

Implementing Notifications

With the app fully functional, the final thing I needed was for it to be useful. While notifications worked in the browser, I wanted notifications to be pushed natively to devices. Some mobile browsers don't allow push notifications unless it's a Progressive Web App, so I had Lovable package the app as one.

This step was challenging because, although I didn't think I needed to, I initially failed to specify that I wanted push notifications to work on all operating systems, specifically iOS and Android. A step that would fix push notifications for iOS would break for Android. After unsuccessful back and forth with Lovable, I turned to Google's Gemini to review the code that Lovable provided.

This approach works on iOS because iOS uses the Web Push API for PWAs, which handles the notification directly. However, it's not working on Android because this isn't a true push notification. It's a web notification, which requires the app to be in the foreground or at least actively running in the background. Android's stricter resource management and app lifecycle handling often terminate background processes, preventing these notifications from being triggered. The issue isn't in your React code but in the fundamental difference between how iOS and Android handle web notifications and PWA capabilities. To send a true push notification on Android that can be received even when the app is closed, you must use a service worker and a push service, like Firebase Cloud Messaging (FCM).

Firebase Cloud Messaging (FCM) allows for universal push messaging across devices. A quick Google search let me know that I was able to use this with Lovable/Supabase.

I want to change the push notification system using Firebase's Cloud Messaging service since that is supported by Supabase. Can you update the push notification logic to use firebase's cloud messaging service.

After another round of debugging with the console and reporting it to Lovable, notifications were being properly sent to customers when their orders were ready. However, when customers placed an order, baristas weren't receiving a push notification. I thought that maybe Lovable hadn't changed the code for that specific use case.

Push notifications are working for customers when their order is ready. However, the logic to send notifications to the barista when a customer places an order is not working. Can you diagnose this issue and see how to fix it? (Since we recently switched the push notification logic to leverage Firebase Cloud Messaging, there may be some updates needed) The push notification logic for OrdersContext.tsx to send the order complete push notification to the customer works perfectly. However, the push notification logic for useBaristaNotifications.tsx doesn't work to send notifications to a barista when an order is placed. What is the difference between the two and how can we fix it?

After getting a 404 error from FCM, this time I asked ChatGPT what the source of the error was and it was because Lovable was using deprecated APIs.

Finally, the app was completed.

Notification Challenges

Because this is a PWA and not a native mobile app, the notifications aren't perfect. Progressive Web Apps don't work in the background so the app needs to be "initialized," i.e. opened in order to anticipate an incoming notification. I'm nowhere near knowledgable enough with service workers to get Lovable to implement and debug it correctly, so this limitation will do.

What I Learned

Decouple what a "prototype" is from Figma prototyping.

Initially, I wanted to accomplish what was "easier for me," which is create the interactive prototype in Figma and have a tool somehow read that prototype to translate into an app. As a designer, this is my path of least resistance: I revel in the work of a clickable prototype that utilizes variants, variables, and conditional logic in order to illustrate exactly how I expect the behavior of user flows.

However, although I love doing it, I know that this is time consuming, and if I'm the "dev" that I'm handing this off to, the time and effort spent won't help me. Instead, I had to rewire my brain to use the AI tool to write and create the prototype interactions. I had to learn that describing it to the tool to build was replacing my interactive prototype and handoff to a dev.

Use all the tools available.

I would not have achieved what I did by only using Figma or trying out different tools to find which suited my needs. Even then, I would not have learned technical knowledge that Lovable assumed I had. Especially since Lovable charges credits per regular chat messages, I needed to look to Gemini and Google searches to better understand that the AI was doing.

How to productively communicate with an LLM.

While making requests, I would make the mistake of assuming that the chat would consider my previous inquiries and its fixes when addressing the task at hand. In reality, the AI would only be reading what I had just asked it. Each message needs to be explicit and include as much context as possible in order to get an answer that doesn't require a follow up question.

Additionally, attaching "Why is this happening?" after every bug fix request would greatly improve the quality of the response and explanations of why something was behaving unexpectedly and, by doing so, would attempt solutions that directly correlated with what it said to be errant.

What's Next

I want to explore the other tools on the market (try Figma Make again, v0, Bolt, etc), to see which tools fit which use cases.

As a designer, I'm excited that I have another tool in my belt to get the job done more quickly, efficiently, and sufficiently. I'm looking forward to seeing how AI builders evolve advance and see the extent of their technology.