How to turn a vibe coding idea into a working prototype: which tools to use, how to plan your first session, and the habits that stop projects from collapsing.
Last week I wrote about how Co.llab started: the non-developer vibe coding story that got 40,000 impressions on LinkedIn and led to conversations with CLOs, an investor, and several people who turned out to be competitors. If you missed it, start there first.
The response surprised me. Not the numbers, the messages. A lot of people said some version of the same thing: I've had an idea like that. I just don't know where to start with vibe coding.
This piece is for them. Not a beginner's guide to AI. Not a tool comparison. A practical answer to the question of what you actually do when you've got something in your head and you want to find out whether it's possible.
Key Takeaways
- Start with the idea, not the tool. Answer three questions before you open anything.
- Not all projects are equal: scripts and internal tools are the easiest starting point. Web apps are next. Desktop and mobile apps are significantly harder.
- The tool you pick matters less than how clearly you brief it. Quality in, quality out.
- The AI has no memory between sessions. You have to be its memory, so write things down.
- Don't write a PRD before you build. Build first, then let the AI write the PRD from the conversation.
- The habits that make projects sustainable (git, focused sessions, testing every change) matter more than which tool you choose.
Start with the idea, not the tool
The first mistake most people make when they start vibe coding is opening the tool before they've done any thinking. They describe something vague to the AI, the AI produces something plausible-looking, and they spend two weeks iterating on the wrong thing. I am particularly guilty of this and it's a habit I'm actively trying to break.
Now before I touch anything, I make myself answer these three questions:
What is the one thing this does? Not five things. One. The most common reason for early projects to stall is that the idea is actually several different ideas dressed up as one. "A platform for freelancers to manage clients, invoices, and projects" is three things. Pick one. Build the version where you could explain it to someone in a single sentence.
Co.llab, at its simplest: you describe what you want people to learn, and the AI builds the course. That's it. Features, capabilities came later. If I'd started by trying to build all of it, I'd still be building the first screen.
Who is this for, and what problem does it solve for them right now? Not eventually. Not in theory. Right now. The clearest sign that an idea is ready to build is that you can name a specific person who has a specific frustration that your thing would solve.
What does the simplest useful version look like? Not the finished product. The version that would be useful to someone even if every other feature didn't exist yet. Developers call this an MVP (minimum viable product). For our purposes, think of it as: what's the smallest thing that would make the person you named in question two say "yes, that helps"?
Write those three answers down. Physically. Before you open anything.
Pick the right kind of project
Not all ideas are equally suited to this kind of build. Before you commit time and energy to something, it's worth being honest about what you're actually trying to make.
The easiest first projects are internal tools and scripts: something that helps you or a small team do a specific task more efficiently. A spreadsheet that processes data automatically. A form that collects information and sends it somewhere useful. A report that generates itself. These are low-complexity, low-stakes, and you'll see results quickly. If you've never built anything with AI before, this is where I'd start.
Web applications (a tool that runs in a browser, has a user interface, and possibly saves data) are the next step up. Still very achievable, but they involve more moving parts: a front end that the user sees, a back end that stores and processes data, and usually some kind of authentication if multiple people are using it. Most of the consumer AI tools are optimised for exactly this type of project.
Desktop applications are harder. They need to work on different operating systems, they behave differently from web apps, and they require more setup.
Co.llab is a desktop app, and I won't pretend that was the easy choice, but it suited the problem I wanted to solve. The output is a file: a SCORM package that gets loaded into a corporate learning system. That's inherently a desktop workflow. And because users bring their own API key, their credentials and their content stay on their machine, not on my server. The constraints of the problem decided the architecture before I did.
Mobile apps are the hardest starting point. Don't start here. Two separate ecosystems, two approval processes, and a set of constraints that don't exist anywhere else. If your idea works on a phone browser, that's good enough for now.
If your idea falls into the harder categories, that's not a reason not to build it, just be realistic about the learning curve before you start.
The vibe coding tools landscape
You have more options than you probably realise, and they're genuinely different from each other. I can only speak with authority about the one I use, but here's an honest map of the territory.
Lovable and Bolt are the ones that get the most coverage right now, and they're popular for good reason. They're designed specifically for non-developers who want to build web applications: the interface is simple, you describe what you want, and they produce something that looks like a real product very quickly. The trade-off is that they work best for a specific type of project (web apps with a front end, a database, and user accounts). If that's what you're building, they're probably the fastest route to a prototype you can show someone.
Replit sits somewhere between the consumer-friendly tools and the developer tools. It runs in a browser, which means no setup, and it has a built-in AI assistant. It's particularly good if you're building something that needs to run on a server (an API, a backend process, a script that does something on a schedule). Less polished out of the box than Lovable or Bolt, but more flexible.
Cursor is a code editor (like the professional tools developers use, but with AI deeply integrated into it). It's arguably the most powerful option here, but also the least beginner-friendly. If you're genuinely comfortable looking at code and don't mind learning as you go, Cursor is exceptional. If you want to stay as far away from code as possible, it's probably not where you start.
Claude Code is what I use. It runs in a terminal (a black window with a cursor where you type things and it does them) which puts some people off immediately. But the conversation quality is the highest of anything I've tried. It reasons about your problem rather than just generating code. It will push back if your approach is wrong, explain what it's doing, and help you think through architecture before it builds anything.
The honest version: if you want something visual and fast, Lovable or Bolt will get you there more quickly. If you want something robust, and you don't mind a steeper initial learning curve, Claude Code is where I'd point you.
How to plan your first build
Whatever tool you use, the quality of what comes out is directly related to the quality of what goes in. Most of the wasted time in early projects isn't the AI producing bad code: it's the human giving unclear instructions.
Before your first session, write a brief. It doesn't need to be long. It needs to answer:
- What does this thing do? One paragraph. The single job it does and for whom.
- What does a user do when they open it? Walk through the simplest possible journey from arriving to achieving the main thing.
- What does it need to store or remember? Does it save anything? If so, what? User accounts? Records? Files?
- What does it not do? Listing what's out of scope is just as useful as listing what's in scope. It stops scope creep before it starts.
This document becomes your brief to the AI. In your first session, share it before you ask for anything to be built. Ask the AI to ask you questions before it starts. Any tool worth using will have clarifying questions: that's the AI checking its understanding, which saves you from building the wrong thing.
Keep this document. Update it as the project evolves. It becomes your project's memory: the thing you hand the AI at the start of every new session to re-establish what you're building, what decisions have been made, and what's out of scope. The AI has no memory between sessions unless you give it one.
Your first session
Here's what I'd suggest for session one, regardless of which tool you use:
Ask for a plan, not code. Before anything gets built, ask the AI to describe what it intends to build and in what order. Read it. Ask questions. If something doesn't match what you had in mind, now is the time to say so, not after it's built.
Build the smallest thing first. Not the full application. One screen, one interaction, one thing that works. Your job in session one is to get something on your screen that you can point at. Everything that follows is improving it.
Don't iterate endlessly in session one. When the AI produces something, stop. Look at what's there. Note what's wrong. Come back for session two with a clear list of what to change. The trap is spending hours in a single session chasing a moving target: the AI makes one change, introduces a new problem, you ask it to fix the problem, and an hour later you're further from where you want to be than when you started.
Take notes. What the AI built, what decisions were made, what you chose not to do yet. Your future self will thank you. Nothing is more demoralising than rebuilding something from scratch because you didn't write down why you built it the first way.
One thing nobody tells you
You will, at some point, have a conversation with the AI where it tells you with complete confidence that it has fixed a problem, and the problem will still be there when you test it.
This is not a bug. It's the nature of this kind of collaboration. The AI is reasoning about what it did, not observing what you observe. You have to test. Every time. Even when the AI says it's fixed. Especially when the AI says it's definitely fixed.
This is also the thing that sorts the people who ship something from the people who don't. Not technical skill. Not the right tool. The willingness to encounter something broken, not panic, and work out methodically what's wrong. That's the job. It's not glamorous. But it's repeatable.
Taking it further: how to write a PRD with AI
If you get to a point where you have a working prototype (something that does the basic thing, that you've shown to at least one person) and you want to take it seriously, the next step isn't more building. It's more thinking.
Professional product teams use something called a Product Requirements Document (a PRD). It's a written record of what the product is, who it's for, what it does, what it doesn't do, and why every decision was made. It sounds bureaucratic. It isn't. It's the thing that stops a serious project from unravelling.
The way I came to one for Co.llab wasn't by sitting down and filling out a template. It was through conversation. A lot of talking about what I was building, a prototype that showed me what worked and what didn't, more talking, and then (once I knew what I actually wanted to build rather than what I thought I wanted to build) I asked Claude to write the PRD from everything we'd discussed.
That order matters. The prototype doesn't illustrate the PRD. The prototype informs it. You find out what's wrong with your idea by building the rough version first. Then you write the document that describes the real thing.
If you want a structure to work from, PRD templates are freely available: a quick search will surface several. Most cover the same ground: the problem you're solving, who you're solving it for, what the product does, what success looks like, what's in scope and what isn't, and any constraints worth naming. Download one, share it with your AI, and talk through it. Tell it what you've built so far, what feedback you've had, what you've changed your mind about. Ask it to fill in the template from that conversation.
The resulting document won't be perfect. But it will be more honest than anything you could have written before you'd built anything, because you'll have learned things from the prototype that you couldn't have known in advance.
A PRD doesn't make you a product manager. It makes you someone who knows what they're building and why. For a solo builder, that's the difference between a project that has direction and one that drifts.
Making it sustainable: a builder's checklist
Most guides tell you how to start vibe coding. Nobody tells you how to keep going without losing your mind or your codebase. These are the habits that make the difference between a project that ships and one that gets abandoned in month two.
Set up git before you write a single line of code. Git is a version control system: it tracks every change made to your project, and lets you roll back to any previous state. Think of it as an unlimited undo button with labels. Every AI tool worth using will help you set it up; ask it to on day one. The reason this matters: the AI will, at some point, make a change that breaks something that was working. Without git, your only option is to try to remember what it changed and ask it to change it back. With git, you take a snapshot before every significant change and you can restore it in seconds.
Start each session with a written goal. One sentence: what does done look like today? Not "work on the app." "Add the ability for users to upload a file and have it appear in their dashboard." Specific, testable, completable. This keeps sessions focused and gives you a clear stopping point.
Set up a memory file, and ask the AI to maintain it. Claude Code has no memory between sessions by default, but it has two built-in mechanisms to fix that. The first is a CLAUDE.md file (a plain text file you put in your project folder that Claude reads at the start of every session). Put your project brief here: what you're building, key decisions, what's out of scope.
The second is auto memory: Claude can write its own notes as it works, storing things like build commands, debugging patterns, and architecture decisions it discovers. At the end of each session, ask Claude to log what was done and what needs attention next. At the start of the next one, it reads that file before it does anything else. The AI doesn't have to start from scratch, it just needs somewhere to write things down.
Work in short, focused sessions rather than long runs. Two hours of focused work beats six hours of gradually degrading context. AI tools have context windows (a limit on how much they can hold in mind at once). In a long session, the AI starts to lose track of decisions made at the start. Shorter sessions with clear briefs produce better, more consistent output.
Ask for a code review before adding new features. Before you build the next thing, ask the AI to review what already exists. Ask it: "Is anything here that could cause problems later? Is there anything I should fix before we add to this?" Catching problems early is dramatically cheaper than unpicking them after you've built three more features on top of them.
Test after every change, not at the end. Every time the AI makes a change, test it before asking for the next one. Not at the end of the session. After every change. This sounds slow. It isn't: it's the thing that makes everything else faster, because you catch problems when they're small rather than when they've compounded into something you can't diagnose.
Don't add features when something is broken. When something stops working, fix it before building anything new. This sounds obvious. It isn't, because the temptation when something is broken is to move past it and come back to it later. Later never comes, and you end up with a broken thing buried under three new features.
A last word on the idea
The question I get asked most often isn't "which tool" or "how do I start." It's: "is my idea worth building?"
My honest answer is that I don't know, and neither do you, and the only way to find out is to build the smallest version of it and show it to someone. Not a survey. Not a landing page with an email capture. An actual working thing you put in front of a real person and watch them use.
That part is uncomfortable, and no AI tool makes it less so. But it's the only test that counts.