The perils of Vibe Coding

I wanted to test some of the vibe coding AI designers and builders that are available now and understand how they worked. I had a cool idea, I had some free time, and I had the hunger to learn.

After trying out a few different things, I settled on Lovable.dev. Markur wasn't at the point of being super serious, and by "super serious", that meant spending a ton of money on it, but It was getting there. I had some pretty robust security. I had some fairly solid testing on desktop and mobile. I had a great pipeline from development to production, and it was all running smoothly.

And by not being "super serious", I mean not really spending the money to do it absolutely right. Had I been serious, I'd have had a proper set-up with safeguards, backups and people that know what they are doing.

I had ... none of that.

Markur did not collect any sensitive or sensitive-adjacent information other than an email address; and the only users we had were family members. I did safeguard those very well. Security was not the problem.

The problem was the cost of doing business. Businesses spend a great deal of money on things like designing, building, securing, hosting ... and when you are vibe coding you are taking that risk and placing it on your shoulders. You can do most of this yourself if you have the time, the patience, the willingness to learn, and the budget to do so.

For me, it was the budget to do so.

I had already spent a few hundred dollars on testing the various AI tools and settled with a solution where I'd use Lovable to design and build the site, integrate with Supabase for the database, push to GitHub, then push to Vercel to be compiled and hosted.

It was all running splendidly.

However, having it up and running was not my goal. I wanted to keep learning, keep pushing, and keep building new features.

I had an idea to add a feature which seemed fairly benign. I created a well-written prompt and continued with the process that i'd used for a few months now of entering the info, testing the result, and deploying when I was satisfied.

Lovable has had a way of saying it was doing something, and it not actually doing it sometimes. Maybe it misinterprets what you say; maybe it doesn't have enough information and tries to fill in gaps (oftentimes incorrectly); maybe it does things incorrectly. And it's that last thing that contributed to the death of Markur.

As I was going back and forth with testing the functionality, I started to get really strange responses from Lovable. Code was showing where it shouldn't, was malformed, and sentences were duplicating certain phrases multiple times within a sentence.

Something was wrong.

There are three safeguards here: You can roll back to a stable place (which I did); You can not deploy to production (which I hadn't); and you can restore your database. Only, you have to have a backup to restore to.

Oops.

And to top things off, I was out of ”credits", which is like the gasoline that makes the engine run. No credits, no running. I had subscribed at the $200 a month tier already, and I'm roughly 2 weeks away from it recycling again. I didn't want to "upgrade" my tier and pay any more money to fix it, and I didn't want it to sit out there broken. I couldn't even troubleshoot the issues and have it try to fix anything because it was out of credits.

And because I spent hundreds of dollars on testing the AI dev tools, I went with the free versions of Supabase and Vercel, the host. I didn't want to spend money on Lovable, Supabase and Vercel monthly for my proof of concept hobby site.

What I didn't realize was that I couldn't revert Supabase to before it had been altered by Lovable because I was on Supabase's free tier, which does not provide a backup. Somehow Lovable deleted the table in my database that contained the user profiles. Everything was based on this user profile. And I had no idea how to actually go back and recreate it ... especially without any credits left within Lovable.

Sure, I likely could have used another service to try to fix this, however, it had gotten so intricate that I would have had to start over. I'd already spend several hundred dollars at this point, and I didn't have the stomach, patience or budget to deal with the aggravation of going through constant bugs during what would be a very laborious and expensive QA process. So I nuked it all. Markur, at least this iteration of it, was dead.

I've been working in web design and development for a long time, so I knew the risks. Since this was a hobby site, I was OK with those risks. This was a learning exercise for me, and I felt like I learned a lot about how these services work from design to building to deployment.

For many folks, this is not a hobby. They are using vibe coded apps to build their businesses on and their livelihood depends on them doing what they are supposed to do.

Vibe coding is an attractive answer to the problem of running a lean business. You theoretically don't need a designer, a team of developers, a database manager or staff to support it. But just like everything else in this world, you get what you pay for.

If you have to rely on a vibe-coded solution, here are some critical things you have to pay attention to if you are running an actual business on it:

Design
Since these all use a common libraries for UI, a lot of them will look the same. Some of them will implement designs given to them, but some won't. Try to be as specific as you can in what you want it to do and what you want the UX to be. Have a plan and share that plan with your vibe coding application.

Build
Have a plan on what you want to implement in order of complexity from easiest to most difficult. Test thoroughly every step of the way. Do not commit to production until you are absolutely certain everything is operating the way it should be. Most of these vibe coding apps use common frameworks that you can take snippets from and input into another AI app, have it fix problems, and then take that fixed snippet and put it where it needs to be in your app.

Backups
This goes without saying, but back up not only your code but your database so you don't run into issues like I did that are mission-critical to your business. This is not an area to skimp on when your livelihood depends on it.

Security
Make sure everything is protected and secure, and there are no ways that your data can be compromised. It's your duty as a site owner and administrator to protect your user's information. Run consistent security checks using multiple services to ensure you are doing as much as you can to safeguard that data.

As for me and Markur, building Markur led me to a bunch of ideas that I have a lot more passion for, so I'll likely be pursuing them instead of trying to rebuild the site.

I'll keep you posted on that journey here.