I Built an App Over a Weekend With No Code. Here's What You Should Know.

Yesterday I made the case that vibe coding platforms need three things to reach non-technical builders: start with who the user is, offer suggestions at every step, and show visual previews before generating code. Today, something more practical: what it's actually like to build something.

I built a prototype called Compass, a guided layer on top of Claude Code, to test those three ideas over a weekend.

It opens by asking who you are, not what you want to build. Every question comes with tappable suggestions. And before any code is generated, you see a visual preview of what your app will look like.

You can try Compass yourself here: https://compass-by-claude.vercel.app/.

But this issue isn't about the design decisions. Yesterday covered those. Today I want to talk about something nobody tells you: what it actually feels like to build something real when you've never written a line of code.

I'm a product manager, not a developer. I've built over 25 apps since last year across every major vibe coding platform. Here's an honest account of what the process is really like, and what I tell everyone who's about to try it for the first time.

The half hour that saves the whole project

The single most important thing I've learned from 25+ builds: plan before you prompt.

Every vibe coding tutorial starts with "open the tool and describe what you want." That's terrible advice. It's like walking into a meeting with a developer and saying "build me something good." You'll get something. It probably won't be what you wanted. And you'll spend twice as long fixing it as you would have spent briefing it properly.

Before I touched Claude Code for Compass, I wrote six documents. A product spec describing what each screen should do. A design reference showing the visual style I wanted. System prompts for how the AI should behave at each stage. A demo scenario walking through a realistic user session.

None of these were technical. I wrote them the way I'd brief a freelancer: here's what I need, here's who it's for, here's what good looks like. Plain English throughout. The AI didn't need me to know how to code. It needed me to know what I wanted.

That planning is why I built Compass in a weekend instead of a month. The AI is fast. But it's fast in whatever direction you point it. If your brief is vague, it'll build something vague, quickly. If your brief is specific, it'll build something specific, quickly.

I tell everyone the same thing: thirty minutes of writing before you open any tool will save you more time than any prompting trick or template.

Your first session will break, and it won't be the AI's fault

My first Claude Code session failed within minutes. API calls returning errors. Nothing working. I spent an hour thinking I'd done something wrong before realising the problem was a conflict between two tools on my computer.

A developer would have spotted this in minutes. It cost me an hour. And this is the moment I want to be honest about, because every vibe coding success story skips it.

Something will go wrong on your first build that has nothing to do with the AI, your idea, or your ability. It'll be a setting, a version mismatch, a configuration clash. You'll feel like you're doing something wrong. You're not. The tools just weren't set up with you in mind.

Here's what I tell people to do when it happens: describe the error to the AI. Paste the error message into Claude and say "I don't understand this. What's wrong and how do I fix it?" Nine times out of ten, it'll tell you. The same AI that builds your app can debug its own environment. I wish I'd known that on my first build instead of spending an hour Googling.

The friction is real. It's not a reason to stop. And it gets dramatically easier after your first project.

The AI is faster than you. That's the point.

Once the environment was sorted, Claude Code built at a pace I wasn't ready for. Within one session it had created the full layout, the conversation system, and live preview rendering. Things were appearing on screen that I hadn't explicitly asked for.

My instinct was to slow it down. That was a mistake. The speed is the whole point. What you actually need is a way to evaluate what it's built, not to make it build slower.

The rhythm that works: give it a focused task ("build the sidebar with session management"), let it run, then review the result before giving the next task. Small prompts, frequent reviews. Not "build the whole app" in one go.

Think of it like directing, not coding. You're not writing the script. You're watching each scene and saying "that works, move on" or "that's not right, try it this way." The AI is the production crew. You're the director. You don't need to operate the camera. You need to know what the shot should look like.

Every build where I've seen people get into trouble, including my own early ones, the pattern is the same: too much given to the AI at once, then no way to tell which part went wrong. Smaller tasks, reviewed more often, always beats one big prompt.

Your words matter more than the code

Here's something that surprises people when I tell them: the biggest improvements to Compass came from changing copy, not code.

When the home screen said "What do you want to build?" people froze. When I changed it to "You don't need to know how to code. You just need an idea," people clicked. When app ideas were labelled "Invoice tracker" and "Appointment scheduler," people hesitated. When I relabelled them "A simple tool to track which clients owe you money" and "A booking page where customers pick a time slot," people chose in seconds.

Same functionality. Same screens. Different words. Massively different response.

This is where non-technical builders have a genuine advantage. If you've spent your career communicating with people, writing for customers, briefing teams, selling ideas, you already have the most important skill in vibe coding. It's not programming. It's knowing how to describe what you want and how to write for the person who'll use it.

The developers building these platforms are optimising for technical precision. The users need human clarity. If you can write a clear email, you can write a clear prompt. And you can write better app copy than most AI-generated defaults, because you think like a user, not an engineer.

Where to start

After 25+ builds and helping others through their first, here's what I recommend:

Start smaller than Compass. Your first project should be something you can finish in a single session: a personal dashboard, a simple form, a landing page. Get the full cycle of plan, build, review, ship under your belt once. Then go bigger.

Save your prompts. Every prompt I write is a template I reuse across projects. "Show me a wireframe before generating code." "Build this one screen at a time and show me after each one." "Use plain English labels, not technical terms." Build your own prompt library from day one.

Brief the AI on your user, not just your app. I always include a section describing who will use the thing and what they'd find confusing. The AI uses that context throughout, generating simpler labels, adding help text, choosing friendlier layouts. It can design for your user. But only if you tell it who that is.

You can do this

I don't say that in a motivational-poster way. I mean it practically. The AI handles the code. You handle the thinking: what to build, who it's for, what it should feel like, whether the result is right.

That's product management. It's also what every small business owner does when they brief a contractor, what every teacher does when they design a lesson, what every consultant does when they scope a project. You already have the skills. The tools just caught up.

The Atomic Builder is written by Faisal Shariff and powered by Atomic Theory Consulting Ltd — helping organisations put AI transformation into practice.