Lovable BBQ is Live on the App Store
Find your next BBQ adventure
TL;DR
I rebuilt and rebranded the pitmasters passport app as lovablebbq.com using a no code application called Lovable.dev
The Lovable BBQ app is now on the Apple app store and coming soon to Android via Google Play
Go try it out and let me know how it works
If you’ve been reading this newsletter for a while, you know about Pitmasters Passport. It’s the BBQ discovery app I originally built in Cursor with Claude Code (and way over architected). Find barbecue restaurants anywhere in the world, check in, track your journey, earn badges. I wrote about the disaster that was Version 1, the lessons learned, and the much simpler Version 2 that actually works.
I essentially combined my two passions for technology and BBQ.
But a question I couldn’t stop asking myself: could I build the same app using a no-code/low-code tool like Lovable?
What is Lovable.dev?
Lovable is a no-code/low-code platform that lets you build full-stack applications by describing what you want in plain English. Instead of writing code in an IDE, you prompt your way to a working app with UI, backend, and integrations generated for you.
Could I use that to re-create or even improve my BBQ app?
Not a watered-down version. The real thing. Google Maps integration, geolocation, check-ins, a leaderboard, badges, Supabase backend, the whole deal. Same PRD. Different tool.
So I ran the experiment.
I also decided it was time for a rebrand. Pitmasters Passport is a mouthful. Try saying it three times fast. For this version, I went with Lovable BBQ. A hat tip to Lovable.dev for creating the app’s foundation, but also just a shorter, more memorable name. Sometimes the simpler name is the better name. And in my opinion, what’s not lovable about BBQ?
The Setup
I took the product requirements document (PRD) I had already written for the BBQ app and fed it directly into Lovable. The requirements were specific:
Google Maps with geolocation to find nearby BBQ restaurants
Multiple search options (current location, zip code, city/state, even international)
Restaurant detail pages with Google Photos integration
Check-in system with proximity verification (you have to be within 150 meters)
User stats dashboard with visit historyBadge system (Backyard Griller at 5 visits, Smoke Chaser at 15, Pitmaster at 30, BBQ Legend at 75)
Global leaderboard
Dark BBQ theme with smoke and fire color palette
Mobile-first design Supabase auth and database
That’s not a simple app. I was genuinely curious whether Lovable could handle it.
What Lovable Did Well
I’ll start with the good news. Lovable’s first pass was genuinely impressive.
I gave it the PRD with some initial instructions to build a mobile-first application based on the requirements, and let it work. Within minutes, it had scaffolded out a working application with a map view, restaurant cards, a check-in flow, and the beginnings of a user dashboard. The UI looked clean. The dark BBQ theme came through. The general structure made sense.
For someone who isn’t comfortable in an IDE, watching your app take shape in real-time from a text description is pretty powerful. No terminal. No file structure to navigate. No package.json to manage. You’re just describing what you want and watching it appear.
The iteration process worked well too. When the Google Maps API integration needed tweaking, I could describe the problem in plain English and Lovable would adjust. When the profile page and settings needed work, same thing. Describe the issue, watch the fix. The leaderboard took a couple rounds to get right, but we got there.
The Supabase integration was solid out of the box. Lovable connected to Supabase for the database and authentication, which meant I had a real backend with real data persistence without configuring anything manually.
If the goal was “build a web app that works in a browser,” Lovable delivered. The application functioned. The design was good. The core features worked. For a non-technical person building their first real application, that’s a huge win.
Where It Got Complicated
A Lovable app can behave like an app on your phone (what’s called a Progressive Web App), but it’s not the same as something installed from the App Store.
And this is where Lovable’s current limitations showed up.
Making it a real mobile app was not straightforward. Lovable builds web applications. Getting from “web app that looks good on a phone” to “actual app in the App Store” required installing Capacitor, which is a technology that wraps web apps into native mobile containers. Lovable didn’t make this process particularly clear or easy. It was doable, but it wasn’t the smooth conversational experience that the rest of the build had been.
Apple and Google have specific requirements. Apple requires Sign in with Apple. Google Play expects Google Sign-In. These aren’t optional if you want to be in the stores. Configuring these authentication methods within the Lovable environment wasn’t something I could just describe in chat and have it handled.
So I had to get my hands dirty. Here’s what I ended up doing:
Cloned the repository from Lovable to my own GitHub. Disconnected from Lovable’s Supabase instance and migrated to my own Supabase database. Manually configured Apple Sign-In, Google Sign-In, and email authentication. Set up the Capacitor build pipeline for iOS and Android. Created a landing page at lovablebbq.com
None of this was hard for me because I’m familiar with these technologies. But if I’m being honest about who this newsletter is for, a non-technical person would have hit a wall at the Capacitor step. And that’s the point of this evaluation. I need to tell you where the wall is.
Lovable BBQ has already been approved for the Apple App Store and is available there for free. Google Play availability is coming soon.
The Takeaway
Let’s talk about where Lovable sits right now based on this experiment.
Lovable is excellent for:
Building web applications from a text description. The conversational workflow is the real deal. You describe, it builds, you iterate. For web apps, this process works well.
Rapid prototyping. If you want to test whether an idea has legs, Lovable can get you to a working prototype faster than almost anything else. The PRD-to-working-app pipeline is genuinely fast.
Non-technical builders who want a web-based tool. If your end product is a website or web app (dashboard, client portal, internal tool, landing page), Lovable can probably get you there without ever touching code.
Database-backed applications. The Supabase integration means you get a real database, real auth, and real data persistence without manual configuration. That’s a big deal for someone who doesn’t know how to set up a backend.
Lovable is still figuring out:
Native mobile apps. The path from Lovable web app to App Store submission is not smooth yet. It requires stepping outside the Lovable environment and getting into technologies like Capacitor, Xcode, and Android Studio. That’s a significant jump for the target audience.
Platform-specific authentication requirements. Apple Sign-In and Google Sign-In configuration needed to happen outside of Lovable. This might improve over time, but right now it’s a manual process.
Complex API integrations that need fine-tuning. The Google Maps and Places API integration worked, but required several iteration rounds to get the behavior exactly right. APIs with nuanced configuration still need some patience.
The important nuance: Most of these limitations aren’t permanent problems. They’re “Lovable in April 2026” problems. The platform is actively evolving, and I wouldn’t be surprised if native mobile app support gets significantly better in the coming months. Maybe they already have capabilities I haven’t fully explored yet. I’m going to keep testing.
What This Means For You
If you’re a non-technical builder reading this, here’s my take.
For web apps, Lovable is a legitimate path to shipping something real. Not a toy. Not a demo. A real, database-backed, user-authenticated web application that you built by having a conversation. That’s worth something.
For mobile apps, you currently have two options. You can build in Lovable and accept that it’ll live as a mobile-friendly website (which is perfectly fine for A LOT of use cases). Or you can build in Lovable, get 80% of the way there, and then bring in some technical help for the last 20% of getting it into the app stores. The second approach still saves you a massive amount of time and money compared to starting from scratch.
The code Lovable generates is real, portable code. When I cloned the repo and migrated to my own infrastructure, everything came with me. I wasn’t starting over, I was building on top of what Lovable had already created. That portability is one of the things I like most about the platform. You’re not locked in.
A Note on Process
One thing I want to call out: the PRD made all the difference. I didn’t walk into Lovable and say “build me a BBQ app.” I gave it a detailed requirements document with specific features, data models, UI preferences, and security rules. That level of specificity is why the first pass was so strong.
If you’re going to build anything with Lovable (or any AI tool), write your PRD first. We covered how to do this a few articles back. That investment pays off every single time, regardless of what tool you’re building with.
What’s Next
I’m going to continue experimenting with Lovable for different types of projects. I want to figure out the best workflow for non-technical users who want to go from idea to deployed app with minimal friction. There will be more articles on that process.
In the meantime, check out the app features at lovablebbq.com or download from the App store. And if you have a BBQ restaurant you think I need to visit, you know where to find me in the comments.
-Ed