3 weeks ago I went to dinner with a friend of mine who runs an independent lawn care business. As you can imagine, because we work in completely different worlds - we don’t usually have a lot of crossover in what we do.

However, this particular evening was different. During the conversation he mentioned he was using this website to manage his business and was frustrated with the experience. I was instantly intrigued and asked to check it out. He pulled it up on his phone. I was stunned. There in front of me was a 10+ year old web app that aged poorly. It wasn’t responsible/mobile-first and was shrunk down so small it was hard to read. I laughed and blurted out that I could probably build a better version with AI in a week or two.

As soon as it left my mouth, my gears started turning on how I would build it. Bolt.new? Lovable.dev? Replit.com? What would be the best option? How could I get something built quickly to test and see if there’s product-market fit. I asked him point blank, “Dude, would you pay like 10 bucks a month for a better version of this?” Without flinching, he said “100%!”

And so, for the past couple weekends I’ve been vibe coding an app focused on independent, solo landscapers and lawn care pros that launched today.

For this edition, I’m going to outline some of the key takeaways I had during this process, what was easy, what was crazy hard, and some tips and tricks to replicate it yourself.

Tool stack

For this project I decided to try and push Lovable to the limits and see if I could build an entire production-ready app without anything else other than Lovable and it’s built in integrations.

A few reasons why I picked Lovable:

• It comes with a bunch of great features out-of-the-box

• It uses ShadCN/Tailwind so the UI looks cleaner than some of the other code generation tools out there

• I didn’t have to code anything or use AI in a standard coding tool.

• It has simple one-click integration with Supabase for the backend, GoDaddy for the domain, and Stripe for payments.

How I got started

Starting out, I did deep research with GPT-4o to analyze the competitive landscape and identify common features, pricing, and value proposition. This was really helpful out the gate to get a sense for what the market looks like from a quantitative standpoint, which was supplemented by my buddy’s experience.

After completing deep research, I used GPT to turn the insights into a detailed requirements doc for the product (aka a PRD or Product Requirements Document) to outline what the product would do, how it would do it, and the various considerations and functionality.

From there I took the PRD and asked GPT to generate a series of prompts to feed into Lovable to build out the beginnings of the app. I then started copy/pasting each prompt into Lovable and built out a basic app with dummy data that wasn’t connected to the Supabase backend.

I did all of this stage on my phone while talking to my buddy at dinner. It took ~20 minutes to put together a quick and dirty prototype of the idea in Lovable to test with a real user (my friend).

Back at the bat cave (building momentum)

After demoing the prototype to my buddy, getting him excited about the idea, and agreeing to work on this together — we parted ways and I went home to start jamming with GPT and Lovable on my MacBook Pro on the couch, while watching The Studio with my wife.

I used the new GPT-4o image model to generate some logo and branding ideas. It’s funny how 15-years ago I would have spent weeks on this exercise and I had a pretty decent brand mark and color palette for testing a product within 15-minutes.

My workflow when building in Lovable these days is once I’ve got the bones of the app in place, I prompt Lovable to connect to a Supabase project which takes 2-clicks. Then I start prompting Lovable to scrub out dummy data it built in the prototype feature-by-feature and page-by-page, replacing with dynamic data from Supabase.

I also grabbed a quick domain on GoDaddy for $12 and connected it to the Lovable project with 2-clicks.

Within 3 hours I had a dynamic app, deployed on a custom domain with login/registration, user roles and permissions, and the core features of a basic CRM for a solo landscaper (customers, estimates, jobs, and notes).

I texted the link to my buddy and he was STOKED. Suddenly we were both feeling like this could really happen. We could quickly build and launch an app and blow the primary competitor out of the water.

We quickly chatted on the phone and decided to set a launch date of May 4th and created an Instagram and Tiktok account for the product.

Testing with real users

The following week (last week), we spent some time combing Reddit and our personal networks to find independent, solo landscapers who were interested in getting a demo of the product. We scheduled times and walked them through it. Two key insights we learned:

1. We initially thought having a route planner for a landscaper to map out their route for the day/week would be valuable. Turns out no one really cared about this.

2. The single biggest thing that each landscaper said they wanted was basic invoicing to send to customers after they completed a job. Quickbooks and other platforms were overkill. They just needed something a bit more professional and a basic way to track who had paid them and who hadn’t.

These two insights were incredibly valuable. We quickly pivoted, punted the routes feature, and I started working on a basic invoicing feature. We also spent some time debating the pricing model for the app.. whether it should be based on consumption (ex. 8 estimates per month max), paywalled, or a combination of the two. We decided to simplify to a freemium model with base features free for everyone and two features available to Pro Plan users for $9.99/month.

Then it got really hard

This is the point where the story takes a turn. I had built out the core functionality, but had held off on adding the paywall for different user roles and the ability to subscribe via Stripe. This was a HUGE mistake. Essentially I built the entire app and saved what I thought would be a simple task for the end. Not the case (I should have known). Turns out trying to partition things after they’ve been built and adding payments is really complicated and hard, and AI doesn’t really do a good job of troubleshooting the issues.

During the 1st part of this story I spent roughly 11 hours getting to a fleshed out business plan, monetization strategy, brand/identity, and fully built product with a variety of easy-to-use and intuitive features.

This next part took me 21 more hours (yes you read that right) to figure out. Here’s what happened. Every time I prompted Lovable to solve one problem, 3 others would pop up. I’d try to fix those one-by-one and 3 more emerged. It’s like that scene from the Disney Hercules where he was battling a hydra and slicing dozens of heads at a time only to realize he created an even bigger monster. Oof. Not fun at all.

BUT.. after a lot of pain and anguish, several dozen expletives, and almost throwing my MacBook at the wall 4 or 5 times, I FIGURED IT OUT thanks to a serendipitously planned Vibe Coding Hackathon with a motley crew of builders last night.

Some key takeaways (& free prompts) to avoid the pain I went through

When building an app with Lovable (or really any AI code gen tool), it’s reaaaallllly easy to waste hours playing whack-a-mole (i.e., AI making changes to things you don’t want it to). You prompt it to build a feature/page, it does what you asked, but also decides to change a bunch of other things you didn’t ask it to. And you’re left like 🤬

I’ve discovered a workflow and a series of prompts that have helped me make Lovable get laser-focused on resolving issues/bugs/errors, adding specific components or features, and updating specific elements of a page layout to minimize the whack-a-mole nonsense.

Here’s the basic workflow I’ve been using that has changed the game for me in the last 24 hours by forcing Lovable to focus on one thing at a time and minimizing changes to other parts of the app without being asked.:

1. Focus only on one page/feature at a time. Don’t mix changes to multiple features/pages in one prompt or you’ll increase the probability of whack-a-mole. Drill down to one specific thing and use a numbered list to help Lovable focus on one thing at a time.

2. Use the prompts below while in chat mode (i.e., the blue chip in the “Ask Lovable” bar is toggled on) to create an implementation plan. Don’t try to “one-shot” (single prompt to fix an issue or build a feature) with a prompt. Start in chat mode first so that you can analyze Lovable’s implementation plan and make sure it’s doing the right thing.

   

   Click the blue chat button before using the prompts below.

3. Review the plan for any issues, then approve for implementation or prompt in Chat mode to revise/edit any problems with the plan.

   

   Once Lovable has laid out a solid plan, click the “Implement the plan” button.

Lovable scenarios & prompts

Analyze & create a plan to fix an error

Analyze & create a plan to add a new feature

Analyze & create a plan to change a feature/page

Use at the end of prompt w/ no implementation plan

Wrapping up

I hope you found this edition interesting and insightful. It’s a bit of storytelling, a bit of a sleep-deprived brain dump, and some new tactics I’ve learned through hard knocks.. all blurred into one newsletter.

Frankly, I’m a bit bleary-eyed after spending most of the day trying to get this product built and launched by end of day, but wanted to make sure to get something on paper and not miss a week of the newsletter.

Hope you got something interesting out of this one 😅

Onward & upward,
Drew

P.s. If you’re building cool things, shoot me a note!