I tried Cursor, Lovable, and camelAI before finding a vibe coding tool I could actually use
I'm Isabella - COO at camelAI, in charge of growth and content. I am not an engineer. I have never written a line of code in my life that wasn't generated by an AI. And a few months ago, my co-founder Illiana sat me down and said: "I need you to start vibe coding landing pages. If you're telling me we need an SEO engineer, I need you to be that engineer."
I said, "Oh shit."
This is the story of what happened next.
Chapter 1: Cursor (or, How I Learned to Feel Pure Panic)
Illiana had already done the hard work. She'd built out a landing page template - properly designed, styled, all the structure was there. The gaps were just the content: copy, images, and customizations specific to each integration type we supported. My job was to open Cursor, fill in those gaps, and repeat that for every single connection type on our list.
It sounds simple. It was not simple for me.
The problem with Cursor - at least for someone like me - is that there's no application layer between you and the code. You're sitting there looking at files, looking at folders, looking at a terminal, and the AI is making changes directly to your codebase. Every suggestion it made, I had to just... trust. I didn't understand what was actually happening. I couldn't tell if something was going right or wrong until I previewed it in a browser, and even then, I wasn't always sure.
I felt anxious the entire time. Like, really stressed. There was so much control suddenly in my hands and I didn't know what to do with it.
The setup process at the beginning was also frustrating. There were authentication configurations and project settings that needed to happen before I could even get started - and if you don't know what you're doing, that initial barrier can feel insurmountable. I remember spending an embarrassing amount of time just trying to get the environment working before I'd written a single word of landing page copy.
And then came The Incident.
I was poking around my file directory one day and noticed a folder that had appeared somewhere I didn't expect it. I thought it was some kind of artifact or mistake. A leftover temp file, maybe. I deleted it.
Then I pushed to production.
I broke everything.
I still don't fully understand the exact mechanics of what happened - something about deleting a file that was actually critical to the build - but the result was clear: our product was broken and it was because of me. At a three-person startup, that's not a great moment.
Looking back, the wild thing is that I had the ability to push to production. A non-technical person with no real understanding of the codebase had full deployment access. That's not a criticism of anyone - we're a tiny team moving fast, and that's how it has to be. But it meant that when I made a mistake, the stakes were very real.
Cursor is a powerful tool. It's the right tool for developers. For a non-technical person trying to do content work through code? It was the wrong fit for me.
Chapter 2: Lovable (or, Where Does Your Work Actually Live?)
After the landing page chapter, I tried Lovable for a different project: building out our blog site. The experience was much friendlier. Lovable is easier to use if you're non-technical - the interface feels more approachable, and the AI is good at building things visually.
But I ran into something that confused me for a while: data persistence.
Here's what I didn't understand when I started: by default, when you build something in a tool like Lovable, and you don't have a database connected, everything you do lives in the browser. Just the browser. Locally. Which means:
- Refresh the page → it's gone
- A colleague opens the same link → they see nothing, or worse, they see your cached state
- Someone signs in from a different device → blank slate
I had built what I thought was a real application. It worked great on my laptop. Then I realized that what I was looking at was essentially a very pretty illusion - nothing was actually being saved anywhere. And the flip side of that was also weird: because there was no real auth layer, anyone who opened the app was effectively under the same "account." All your test data, your drafts, your experiments - everyone could see them. There was only one view of the world.
To actually fix this, I needed to plug in a database. In Lovable's case, that meant using Lovable Cloud. At the time, the setup was confusing enough that I found myself going down a rabbit hole of documentation, with only a partial understanding of what I was even setting up or why.
None of this is a knock on Lovable - they've continued to improve, and it may well be smoother now. But it was a lesson in how much invisible infrastructure sits underneath even the simplest apps.
Chapter 3: camelAI (or, Oh, This Is What It Should Feel Like)
By the time I started using camelAI, I'd been through enough that I had a clearer picture of what I actually needed. And camelAI answered almost every question I'd been frustrated by.
Here's what getting started looks like:
-
Connect an LLM provider. I recommend OpenRouter - it gives you access to every major model (Claude, GPT-4o, Gemini, Llama, Kimi K2.6, whatever you want) through a single API key. Kimi K2.6 is a standout open source model that works really well. Set up auto-replenish on your credit card so you never hit a wall mid-project.
-
Connect your data. Drop in a CSV, hook up your Discord server, or connect a database like BigQuery or Snowflake. camelAI integrates with the tools you're already using.
-
Build something. Describe what you want and that's it.
-
Share it immediately. Everything you build in camelAI is automatically hosted via Cloudflare Workers. So, there's no deployment step or server to configure. And definitely no "push to production" button that might break everything. The thing you built is a real URL, right now, that you can send to anyone.
The backend is automatically provisioned. The app is immediately live. If you want to use your own domain, you can do that too - and that setup is also simple.
To give you a sense of what's actually possible, here are a few things I've built or seen built with camelAI:
- GitHub repo analytics - track commit activity, contributor stats, and repo health without touching a terminal
- GitHub PR → Slack notifications - automatically ping your team when PRs are opened or merged
- Discord community analytics - understand who's active, what's being talked about, and how your community is growing
These are real guides built with camelAI. Things that would have taken an engineer days if I'd had to put a ticket in and wait. The anxiety I felt using Cursor? Gone. The confusion about where my data lives that I ran into with Lovable? Not a problem - camelAI handles persistence out of the box.
For someone like me - a non-technical person who needs to build real things and share them immediately with my team - camelAI is the tool that actually fits how I work.
What I'd Tell My Past Self
If I could go back to the moment Illiana told me I needed to become the SEO engineer, here's what I'd say:
You're going to be fine. But don't start with Cursor.
Cursor is an incredible tool for people who already understand code and want AI to make them faster. It is not the right starting point if you've never worked in a codebase and you're doing it alone without a technical co-founder sitting next to you.
Lovable is friendlier - but understand the data persistence model before you build anything you care about. Otherwise you'll build something and not realize it only exists on your laptop.
And camelAI? Start there. It's built for people like us - non-technical folks who need to move fast, build real things, and not accidentally break production.
We're a three-person startup. Non-technical people need to learn how to build. That's just the reality. The question is which tools actually meet you where you are.
I'm Isabella Reed, COO at camelAI. I write about growth, content, and what it's actually like to be a non-technical person building things with AI.