TL;DR: I vibe coded a simple web-app (RunTime) as a way to take a break and clear my head from UX project works. My process, challenges, and learnings are below!

The problem* with running in San Francisco (ok, *my problem)

Over the last year, I’ve taken up jogging (not in a Boston Marathon aspirational way, but in a quick workout in a time crunch way). Since I’m usually cold, I prefer to run earlier in the day to maximize sunlight and minimize wind.

Unfortunately, this is what actually usually happens on a typical Run Day:

First thing in the morning, I make some coffee before my run. It’s a nice day, so I can have a lazy morning. While I enjoy my coffee, I sit down just to “quickly check” on my emails.
*I fall into a swirling vortex, getting sucked into a black hole of time*
Many hours later, my dog comes by to take me for a walk. I realize I’m still in PJ’s and all I’ve had is half a cup of coffee. I’m ravenous and there’s no way I can run on an empty stomach like this!
As I look out my window at Sutro Tower slowly getting consumed by the afternoon fog as the winds are howling, all I can think is: Oh, I really should’ve ran this morning before sitting down… Is it too late to go now?
Sit in regret and pick one of the following:
A. Go outside, grumpily run against the wind, feel my joints crunching away.
B. Decide it’s a lost cause; I’ll try again tomorrow.
Tell myself I’ll do better next time.

After days of this vicious cycle an epiphany hit me: I could build a tool to help me fix this. If I’m going to put off making improvements to my portfolio work, I might as well do something productive in the meantime. Cue what I’m calling procrasti-vibe coding.

Getting a fast first draft with Lovable

I opened up Lovable (my favorite vibe coding tool at the moment), typed in a vague-ish prompt (left), and it spit out a great first draft (right):

Prompt: I would like to create a simple UI that gives me the best window to go for a run in San Francisco, specifically in the NOPA neighborhood. I want the app to track wind speeds, temperature, and sun (cloud coverage/UV), and when I open the app I just want to see 1) a suggestion of the best time of day today to run, 2) a summary of the aforementioned stats, and 3) a comparison from yesterday

I only gave it functional details, so Lovable added in its best suggestions for colors, icons, and a name. It was a great start, though clearly there were flaws in the design.

The AI tool designed something, but it’s not a replacement for a good UX designer. Before building something, it could’ve asked me:

What are your ideal running conditions?
What’s the most important to you?
Where are you running? (This one’s especially important due to the SF microclimates!)
What times are you available?
How long do you run for?

But it didn’t ask any of these questions. The tradeoff is that no good UX designer could manually recreate this first draft in <2 minutes. (No good UX designer would design this in <2 minutes anyway because they’d be focused on narrowing down the problem!)

The freedom of making this experimental app and designing for just myself is that I didn’t need to have those questions answered ahead of time. Hell, I didn’t even know I wanted those questions considered until I saw the first pass of the UI and realized it was missing some user input/customization. I was able to “build” something fast for quick feedback loops, since the turnaround time between requests was only seconds to minutes long.

This invigorated me and really fueled me to keep going with vibe coding, since I previously ran into several roadblocks trying to build Chatful via vibe coding. I gave Lovable (and a few other AI tools) my Figma files and screenshots, and it couldn’t recreate the UI even remotely closely. In building this much simpler app and relinquishing lots of control, I was able to get something workable from the get go.

However, I had a lot of issues as I iterated and added complexity.

Challenge #1: AI is not an Actual Person, so common sense gets thrown out the window

My experience using AI to code so far has been… like I’m talking to someone with short term memory loss. Or an intern that’s afraid to upset me. Or a bunch of kids in a trench coat disguised as a competent coder, switching off who’s at the top of the stack interacting with me but not interacting with each other.

I was seeing weird logic show up in the prototype and switched over to the Chat only function (chatting without editing with each message) to understand what was happening. One time, I asked why I was getting mismatched weather data across cards. Lovable said:

Looking at the current code, the weather data in src/utils/weatherService.ts is actually hardcoded/mock data - it's not being pulled from any real weather sensors or API. The functions like getCurrentWeather() and getHourlyWeatherData() just return static values.

Excuse me — “hardcoded/mock data”?! If I didn’t look hard enough at the math not mathin’, I probably never would have noticed. Lovable suggested a few different free weather APIs to use, but after trying them, most were missing the actual data I needed, so once again Lovable was filling in with mock data so that the interface would look right, even if it wasn’t real.

Why would it do this? No idea. Eventually I had to turn to Reddit forums to see which API people liked using the best, you know, one with… real data. The winner was Open Meteo (which was not suggested by Lovable, by the way).

Another logic issue I ran into with Lovable that would’ve been quickly seen as an issue by human eyes was that although I asked it to add in a slider for my available running window, my suggested run time was still outside of my window. It was only once I sent this screenshot to Lovable and used up some more credits that it realized its mistake and fixed the problem. I could feel the sarcasm dripping off its robotic response, the subtext saying: Ohhhhh, I didn’t know you actually wanted me to factor in the time window, why didn’t you say that the first time around?

With tools like this, you often have to wait until you see the issue and show it what doesn’t make sense so it can go in and fix it.

Some other issues I ran into:

Not creating time slots after 3:30PM, so all parameters showed no available times anytime I checked after 4pm
Suggesting a later time was better because the wind would go up to 17mph (yuck)
Suggesting a later time was better because the temperature would go down (the opposite of what I wanted, SF almost never too hot for me!)

When I used the Chat function to ask what was happening with the logic issues, I was getting messages like this:

With each iteration, it added and edited lines of code here and there. To validate the changes, I would try out different combinations of neighborhoods and time windows to see what it would spit out as a suggestion. Every time it showed suggestions that went against what made sense, Lovable would try to troubleshoot. It seemed like each modification remixed on code that already wasn’t perfect, and suddenly bugs were taking more requests and edits to fix. The Chat function became more and more useful as I needed it to decipher where issues in the code were.

I was partnering with the Chat function and then taking it to Lovable for actual code changes. But of course, there were still UI problems trying this method out.

Challenge #2: Lack of coding knowledge = UI edit request doom loops

Since I was mostly focused on the functionality, I let Lovable take the driver’s seat for most of the visual design. However there were some UI issues that it struggled to correct, like popover placement, container opacities, and text/color contrasts.

Similar to the logic issues, most of my UI issues were easily fixed by taking screenshots, describing the problem, and sending them into the chat. Some were immediately fixed after the first message (like the time being displayed as 12 P:30M) but some took 5-6 messages back and forth (adding the second slider handle and fixing the popover alignment). It was like Lovable’s short term memory loss would kick in, causing a new problem in one iteration, only to proudly remove it in the next iteration. My guess is that since there were so many files/locations that it needed to sort through and Lovable couldn’t actually see what I was trying to fix, it couldn’t make the correct changes or validate them.

For some extreme cases, I spent an embarrassingly large amount of time on incredibly basic changes. For example, two of my containers had mismatched background opacities. I’d rinse and repeat sending a screenshot and requesting the behavior/change I wanted, but there are only so many variations of “can you make them match, one has a lower opacity than the other” that one can come up with.

I decided to open up the code editor and take a look under the hood. For someone who has no idea what language Lovable’s even using, this (below) is a terrifying thing to see, but I honed in just on the bg-white/XX and attempted to change the opacity. That much I could figure out.

Did I change the most basic thing? Yes. Did I suddenly feel like a programmer? Also yes.

It was after these hours of chatting and manual edits to the styling that I decided to take a peak at my credit usage. I’m on Lovable’s 100 credit/month plan, and I hadn’t checked on my usage since after getting the basic functionality of the app figured out. It only took about 40 credits to get a working prototype, but I was shocked at the amount of credits I burned making mostly visual changes.

I turned to ChatGPT to breakdown what I was seeing and the AI Overview in Google Search to help me find resources. There was a low likelihood I could “figure out” TypeScript by looking at it, but I figured I could easily figure out Tailwind CSS. I ended upon the Tailwind CSS website, which was super helpful in understanding basic styling details.

It was very straightforward spending the 10 minutes to learn basic terms for Tailwind CSS and using the Search function in Lovable to solve the rest of my styling issues. I probably could have saved an hour here and there if I had done this sooner, but hey, necessity is the mother of invention, and I wasn’t driven to necessity till I was almost out of credits.

Better done than perfect

After spending several days, 100 AI edits, 132 messages, and after exhausting almost all of my monthly credits, it’s time to call it good enough.

I get 5 additional credits per day I can use to make small changes, but I won’t be spending 4 hours at a time iterating anymore (or not until next month!) Sure, you could say I could just upgrade my plan, but it’s good to have constraints. Without a credit limit, I probably wouldn’t have dove into the code editor. And plus, the subscription costs of all of these tools really add up, especially when you’re using them for personal projects.

As I look back on this project and having used it several times, the most surprising thing was that I wasn’t even using it in the way I initially intended.

What I thought I wanted: The best time of day to go running when the winds are low and the temperature is warm

What I thought I meant: How late in the day do I have to run before it’s miserable out?

What happened 90% of the time: I guess I have to go on a run now, which neighborhood/park should I run to and which direction should I head out in?

So I found myself mainly using the app to figure out which neighborhood to run to and to understand the temperature and wind speeds at different times of day. For my most recent late afternoon run, I decided to go south rather than west. I left my neighborhood and jogged into the sunshine and low winds near Dolores Park, rather than jogging into the fog, where the wind was only increasing and temperatures falling.

For future iterations (and when I have more credits to spend at once), I’ll probably tackle simplifying the UI to increase usability. Maybe I don’t need all of the supporting stats on the home page once the logic has been tested, but rather show suggested neighborhoods to run in. It may also be more beneficial to use Open Meteo’s Feels Like temperature paired with the wind, rather than trying to calculate my own scoring system across 4 different factors. Maybe in its final form, it will be a Mr. Chilly type app that has a thumbs up or thumbs down over the neighborhoods of San Francisco, based on how I’d rate it for running.

But for now, it works just fine for what I need it to do. I have user inputs, weather stats, and map-based search. It’s not perfect, but it’s a solid MVP.

So what did I learn?

It’s important to know what you want before designing. I knew this already, but I thought I had a simple task, so I let Lovable give me a lot of suggestions. I wasn’t being specific enough with the behavior I wanted and it allowed Lovable to write logic that often contradicted itself due to the code slop and high number of iterations it made.
Constraints will set you free. Having credit limits helped me from getting too sucked in with minutia and it forced me to learn about what I was building, which was incredibly empowering.
Lovable is not a person. It thinks, it reads, it codes, but at this moment of time it doesn’t do it the way a real human would. It gives suggestions and fills in gaps without fully identifying the problem, which means it can never take you 100% of the way to a solution.

Lastly, I learned how freeing ✨ it is to work on a project that’s just for me. I can iterate, test, fail, all on my own, without worrying about external perceptions. I was so happy to have made this app - I felt accomplished and genuinely glad to have a useful tool built to help me solve my problems. As soon as I pressed Publish and shared it with the world, however, I started to wonder how user friendly it was and worry what other people would think of it. Something I’d like to take with me from this project is the joyful and proud feeling I had after creating something for myself.

If you’ve made it this far, thanks for reading! Let me know how you’ve used vibe coding to improve your daily life or if you have any tips on working faster with Lovable.

Time to log off and go for a run!

Vibe Coding RunTime