Vibe Coding for Beginners — Simple Guide for Creators, Marketers, and Non-technical Folks

I’m not a developer, but boy, can I code.

Vibe code, that is.

Thanks to the help of several AI coding tools, I’ve built upwards of 10 personal apps and tools in the past year: a step tracking tool, a fitness dashboard, several productivity tools, and a content calendar that plugs straight into Buffer’s API.

I’m currently working on an app that will help me cater to the very diverse needs of my harem of houseplants. 🤓

I built all of these things with a couple of different AI coding tools, all of which offer different levels of handholding. These days, I’m super comfortable using Claude Code, GitHub, and the terminal daily.

I will also acknowledge that I had plenty of help. At Buffer, we have dozens of very nice, very helpful engineers who have been unblocking their non-technical peers at every turn. We even had Build Week, a full week outside our regular roles to build a simple tool or workflow with AI.

And before you ask, heck yes — it did feel really, really intimidating at first, even with all the support I had.

But I’m so glad I took the plunge.

Firstly, because it turned out to be much easier than I thought it would be, and secondly, because it has opened up a world of possibilities for me and my work.

I know a lot of my creator and marketing peers are still peering down the “how-the-heck-am-I-supposed-to-do-this?” chasm, and I’d really love to help.

Enter: Vibe Coding for Newbies: The Complete Beginner’s Guide. ™️

It is not a guide to launching a SaaS company, becoming a developer, or shipping anything production-grade. The frame here is small, useful, personal tools: things that will make your work a little smoother, or even stuff you’ll use with your family.

And, be warned: it covers the unglamorous (but very necessary) scaffolding stuff, too.

Most vibe coding guides stop at “describe what you want to Claude,” (it’s a bit more complicated than that — but not much!). Where non-developers actually get stuck is a little further on in the process: where to put your files, when to back things up, and what to check before you put something on the internet.

And I absolutely did ask some of the aforementioned friendly engineers to review this article. So you know you’re in safe hands (thank you, Hamish and Martín!) 👋

By the end of this, you’ll have a setup that won’t lose your work, and a first project small enough to finish.

Ready? You got this! Let’s build.

What vibe coding is

Vibe coding means describing what you want in plain language so that an AI can write the code. Andrej Karpathy coined the term on X in early 2025, and Collins Dictionary even made it their Word of the Year.

The possibilities for creation are almost dizzying, but my preferred use case thus far has been for me- or team-only tools and workflows. Great power, great responsibility, etc. etc.

I know folks much smarter than me who have vibe-coded customer-facing products, but I’d tread carefully there if you don’t have an engineering background. Just for now. Let’s walk together before we run.

There are also things best avoided when you vibe code, even if they’re only intended for you or a handful of people. For example, handling real money, storing other people’s sensitive info, or anything that has to be legally compliant (so nothing medical, nothing financial, nothing with a pile of GDPR obligations attached).

Start small, and start safe.

Note that there will probably be a few unfamiliar words in this article. I’ve done my best to explain everything as it comes up, but I’ve also included a handy glossary at the end! Refer there if you need a deeper explainer.

Where to vibe code: The toolkit you need

You can vibe code with surprisingly little. But before you decide how (the AI tool/s you’ll be building with), you need to decide where.

Fun fact: building your own tools doesn’t actually require you to put them on the internet or ‘host’ them somewhere. They can live exclusively on your device (the catch is that you can’t easily open them on your phone, and building this way might require a slightly more advanced AI tool).

So with that in mind, you’ve got two options:

Browser or laptop

Browser-based building means everything happens in a web app. You sign in, describe what you want, watch it build, and click publish. It’s the lowest barrier to entry by far, and even hosting is included, so you can deploy to (read: make your tool live on) a URL without you thinking about it. The trade-off is that your work lives on someone else’s platform.

Laptop-based building means the files live on your computer (at least at first) and a tool on your laptop talks to those files. More setup, but more control. The code and your tool can live locally forever if you fancy. But if you need your tool to be accessible on other devices and to other people, you can push it to a URL by connecting the project to a hosting platform (we’ll get into all this, I promise.)

Neither is better than the other. While building on your laptop (or other computer) might feel safer, it’s definitely a bit more technical.

To understand why, we need to explore…

The 2 types of vibe coding tools

In order of the technical skill required to use them:

1. All-in-one app builders

These are browser-based AI tools built specifically for vibe coding, with hosting included. Lovable, Bolt, and Replit are probably the best-known names in this category. You tell them what you want, they build it: front end, back end, database, hosting, all in one window, and your app is live in minutes.

I started with Lovable, and I can’t recommend it enough for getting started. It’s super user-friendly and has loads of security checks and balances. The trade-off is platform lock-in — your tool will live there. Your code can come with you if you leave, since Lovable syncs to GitHub, but you’d have to wire up the database and hosting again somewhere else.

2. AI coding agents

These are laptop-based. You describe what you want, and the agent handles the files on your computer: writing them, moving them, running them, testing them. Claude Code, OpenAI’s Codex, Cursor, Devin Desktop, and Gemini CLI are the main ones. This is where I spend most of my time (mostly in Claude Code at the moment).

Some live in your terminal, which is a plain-text window on your computer (I’ll explain it properly in a minute, and it’s much less scary than it sounds). You type in English, and the agent writes code, and you never have to open a file unless you want to. Claude Code, Codex, and Gemini CLI started out this way.

Others, like Cursor and Devin Desktop, live inside a code editor, so the files sit on screen in front of you and change as the agent works.

Most of these tools now do both, so this is less of a decision than it looks. Pick based on whether seeing the code as it’s written makes you feel more in control or a bit befuddled.

Other tools you’ll need to vibe code

AKA: The supporting cast. Depending on the option you choose above, you may need to get to grips with a couple of other tools. If you plan to go with option 1 (a tool like Lovable) for your first couple of projects — I highly recommend you do! — skip this section.

GitHub

If there’s a word that might strike fear into the hearts of vibe coding marketers, it’s probably “GitHub.” I was initially quite intimidated by it until someone shared this analogy:

GitHub is really just Google Drive or Dropbox for code.

So why don’t we just use those things then? Technically, you could. But what’s special about GitHub is that it keeps the receipts.

It keeps every version of your project, so you can easily revert to a previous build if something goes a bit funky. (The system doing that work is called ‘git.’ GitHub is the website built on top of it.More on this in the glossary.) This is the primary reason you might want to consider storing your files in GitHub, rather than locally.

It’ll also keep your files from being washed away if you ahem accidentally spill a protein shake on your laptop one day. (If you think this example is too specific to be untrue, you are correct.)

How do I use it?

Using GitHub requires a (free!) GitHub account, which will only take you a few minutes to set up.

With that done, your agent needs permission to act on your behalf. Ask it: “Walk me through installing the GitHub CLI and signing in.” It’s a one-time setup, and without it your agent can’t create repos for you — you’ll just get an error.

After that, starting a new project means prompting: “Set this up as a git repository and create a private GitHub repo for it.” Let it do the work.

(If that feels like a step too far for now, create an empty private repo yourself on github.com and tell your agent to use that one instead.)

2 rules to remember for GitHub:

Don’t commit your secrets. Secrets = API keys, passwords, anything you wouldn’t want public. Make sure that none of it goes into GitHub (even if you’re working in a private repo).Default to private repos. You can flip a project public later, and public is great when you want feedback or a portfolio. But that’s a Future You problem.

Hosting platform

If you want to use your app or tool on a device other than your laptop, or share it with other people, it needs to live somewhere on the internet.

Enter: a hosting platform. Vercel, Netlify, or Replit are all great free options.

How do I use them:

Again, this is just a case of setting up your account and pointing your coding agent at it. Your agent may need you to do a couple of things here and there manually (mostly just copy-pasting stuff). If you get stuck, ask your agent.

Somewhere for your data to live

The moment your tool needs to remember something between visits — saved entries, a list you add to — it needs a database. Supabase is usually the default here. If that still feels like a step too far, an Airtable base or a Google Sheet can do the same job for a small personal tool. Both need an API key, though, so the security rules further down apply here as well.

How to use it:

Create a free Supabase account, and point your agent at it.

The terminal

The little black box that you can use to run commands on your computer. It’s called Terminal on a Mac and Windows Terminal on a PC.

How to use it:

You don’t need to learn commands, but you may occasionally need to open it to paste things in. Just type terminal in your local search bar to open it. Again, if you get stuck, you just ask your agent to help. Don’t be afraid to share screenshots in your chat!

Node.js

At some point, a tool may ask you to install Node. It’s the engine that runs JavaScript projects on your own machine, and most of what these tools build is JavaScript.

How to use it:

Install it once and never think about it again. Your agent can’t click through an installer or type your admin password but it can talk you through every step. If you’re using Claude Code, Cursor, or Codex, you might want to get ahead of this before you even begin building anything. “Walk me through installing Node on my laptop, step by step” is a great first prompt.

Set yourself up properly

Imagine you’re working with a personal assistant, asking them to tackle a couple of projects that require files. It’s unlikely you’ll hand over 12 chaotic folders without a clear structure. You’ll likely make sure everything is properly named and organized logically (you’re not paying them to clean up /downloads, are you?)

Starting out with a coding agent is exactly the same. The best part – hand them something organized and logical, and they will keep it that way.

Make one ‘projects’ folder. I recommend you do this before you build anything. Somewhere obvious, like in Documents/projects, or on your desktop; it doesn’t matter.One project, one sub-folder, every time. Inside your primary projects folder, all of your builds, tools, or apps should have their own subfolder. Resist the urge to try something experimental inside a project that currently works. If it’s a new idea, it gets a new folder.Name sub-olders properly. app, test, final and final-v2 are not what you want here, my friend. If you ever add anything manually, name them logically.

Prompting when you vibe code: best practices

Prompting an AI agent to build an app is not all that different from asking it to, say, help you find cheap flights, or draft a marketing report. Here are a couple of things that I have found get me great results:

Tell it you’re not an engineer. If your agent doesn’t already have this context on you, it’s worth noting it in the chat; otherwise, you risk having some pretty confusing jargon thrown at you from the get-go. “I’m not an engineer. Explain things to me as simply as you can, without technical jargon.”

Start by asking it to help you plan. This chat will be a marathon, not a sprint. Start by specifying what you want, and specifically add: “Help me plan this before you write any code. Walk me through the structure and what files we’ll need, in plain English, first.” From there, assess the plan and iterate. The agent will likely make a lot of assumptions about how you want things to work. Make sure it’s correct first.

Be specific about what you want. Not “make me a content tool.” Try: “I want a small web page where I paste a paragraph, and it tells me roughly how it would land on LinkedIn — flag jargon, flag corporate-speak, flag emoji-heavy openings.”

Functionality first, form later. Take it from someone who has lost hours redesigning (and redesigning) the UI and branding before checking the tool will actually work how you want it to. Make sure the tool is working how you want it to before you start trying to make it pretty.

Small bites. I know it’s tempting, but try to resist the urge to ask for five different features in one go. Build one thing, test it, then move on to the next.

Share errors verbatim (preferably with screenshots). If you get errors, copy the entire error message in, including the bits that look like hieroglyphics. You can even share screenshots of whatever you’re seeing. Error messages carry more information than they appear to, and summarizing strips out exactly the part that identifies the problem.

Just ask. If you feel stuck or aren’t sure what to do next, ask for guidance. If you don’t like the way something works at the moment, say so, even if you don’t know what the fix is. The agent can present endless alternatives to you.

Ask it to review its own code. When you’re in a good spot with your build, ask your agent to review the code. “Act as a senior engineer and review this code,” is one of my favorite last-pass items.

What about coding languages?

Short answer: the tool picks. You’ll see words like TypeScript, JavaScript, Python, React, and HTML scroll past. You don’t need to choose between them. Web apps end up in some flavor of JavaScript — usually TypeScript and React these days — and scripts and automations end up in Python.

Still, it’s worth knowing that they aren’t interchangeable. If you started in Python and then decide you want a slick front end, that’s a bigger ask than it sounds, because these tools work much better when a project sticks to one stack.

This is another great reason to ask the tool to plan before it builds. As the plan evolves, it becomes clearer which language to use. Don’t request a language by name unless someone has given you a reason to.

Security: what non-developers need to be aware of

Be sensible about what you build, particularly if it isn’t a local-only, you-only app. Here are some security best practices to keep your data safe.

Never put API keys in your code (or your AI tool)

If your app needs to connect to another app or service to work — like how my vibe-coded content calendar connects to Buffer — you’ll need something called an API key (many tools, and even most social platforms offer one). An API key is what lets your app talk to another service, and it functions a bit like a password.

It’s referred to as a ‘secret.’ You don’t want this key:

In your codeOn GitHubIn your AI tool

The API belongs in a file called .env. and I recommend you paste it in there manually.

Your AI agent might ask you to paste it into the chat. Instead, I recommend you drop this prompt in when the time comes to connect to the external app or service:

“I want to keep my API key secure and store it in a .env file, not in the code. Walk me through exactly how to do that. Also, be sure not to expose this key to the browser. Put the call in a server-side function.”

Lock the front door

If you deploy your app to a URL, even if you’re the only person who has that URL, it’s worth locking it. Be specific about how, though, because “make this password protected” isn’t as foolproof as it might sound.

Left to its own devices, an agent will often write the password into the page itself. You get something that looks like a login screen, but the password is sitting in the code where anyone can read it, and it can be skipped past entirely. Not ideal!

There are two things that can help you solve this problem:

The simplest by a mile is to turn on password protection at your hosting platform. Vercel and Netlify both offer this at the site level, with no code involved. (If you can’t figure out how to do this, ask your agent for instructions.)The other is to ask for real authentication.Here’s a prompt: “Set up proper authentication using Supabase Auth. I don’t want the password living in the front-end code.”

Cover all the security basics

Use a password manager, because you’re about to create a lot of accounts. Create strong passwords and turn on two-factor authentication on GitHub, on your hosting platform, and on your AI tool.

Vibe coding ideas: what to build first

The hardest part of starting is often choosing. I often find myself so overwhelmed by the possibilities, I do exactly… nothing.

So here’s the rule I’d give someone in our line of work: build something that solves one small annoyance in your own workflow. Is there a task you’re repeating daily? Or a way you wish you could view reports?

If you’re looking for a little inspo, here’s a full list of some of the most useful things I’ve built:

Buffer Content Team Calendar: A ‘master’ calendar that pulls all our blogs, newsletters, videos, and social posts into a single calendar (it can schedule stuff via Buffer’s API, too!)An email app that pulls mail from all my inboxes into a single hub, classifies them, and marks the ones I need to take action on.Kite Kids: An activity guide that covers children’s activities across South Africa. (My husband and I built this together, and I’m hoping this might turn into a fun side business!)Burrow: A task consolidator that pulls in all my to-dos from different tools, complete with a productive potato desk pet (completing tasks ‘feeds’ him.)A fitness dashboard that allows me to track my workouts and PRs.

And some ideas from the Buffer team:

Brandon built a content engine that produces 21 posts a weekMiguel built a MacOS app that summarizes articles he saved to read laterJoe built an app that adds his Pokemon cards to his store and promotes them via Buffer

From our community:

Shivani built a content library that lets her search, analyze, and repurpose her Buffer postsShe also built her own LinkedIn content command centerVioleta built an AEO content workflow that finds LinkedIn gaps and drafts posts in BufferFahad built an idea engine that finds trending topics and stages them in Buffer

Where to go from here

You don’t need to do all of this on day one. You don’t need to try every tool on this list, learn the glossary by heart, or start chatting about the ‘repo’ at your next dinner party (in fact, I strongly recommend you don’t.)

What you do need is a willingness to be a beginner for a few hours — and the persistence to just keep asking your agent to fix, guide, or explain. That was my crash course.

If you make something, I’d love to see it. Come find me on Threads and show me!

More vibe coding resources

How to Post on Social Media from ClaudeThe Best MCP Servers for Social Media

Vibe coding glossary

API — Short for application programming interface. It’s the doorway one app opens so another app can talk to it. My content calendar pulls posts from Buffer through Buffer’s API. You’ll need one if your build needs access to data or functionality from any other app or service.

Front end and back end — The front end is the part you see and click: buttons, text, layout, colors. The back end is everything happening behind it: storing your data, doing the calculations, talking to other services. A simple tool might be front-end only. Anything that remembers something between visits has both.

GitHub — A free website where your project files live, along with every version of them you’ve ever saved. Google Drive for code, essentially, but with a much better memory. It’s also where hosting platforms like Vercel and Netlify expect to find your project when you want to put it online.

Git — The version tracking system GitHub is built on. Git does the actual work of recording every change you save; GitHub is the website that stores those records and shows them to you. You’ll see the word in commands and in your agent’s replies, and you never really need to learn it directly.

Repo — Short for repository. It’s the folder your project lives in on GitHub. One project, one repo. Keep yours private unless you have a specific reason not to.

Commit — A save point. Every time you commit, git stores a snapshot of your project exactly as it is, with a short note about what changed. That snapshot is saved on your computer until you push it to GitHub, which is why the two usually happen in the same breath. If tomorrow’s version breaks something, you can roll back to the last commit that worked. Commit whenever something works, not just when you think you’re finished.

Secrets — The passwords of the coding world: API keys, database passwords, anything that would let a stranger into something of yours. Secrets never go in your code, never go into GitHub, and ideally never get pasted into your chat with your agent either.

.env — A small file that sits in your project folder and holds your secrets, kept separate from the rest of your code. The dot at the start tells your computer to treat it as hidden. Pair it with .gitignore — a file that tells GitHub which files to skip — and your keys stay off the internet.