A friend recently told me she had an idea for an app and was planning to take some courses so she could learn how to build it.

I told her to take the courses, but start building now. Do not wait until you think you know enough.

I build my Mac apps using Claude Code and Codex. You describe what you want, the AI writes code, and you try it and work through the changes together. This is vibe coding. You still need to check what it produces, but you can learn while building something you want to use.

This guide starts with an empty folder and works towards a small task-list app on your Mac. You will add a task, close the app, and reopen it to find that task still there. That is your first proof of concept: a basic version that lets you try an idea before spending more time on it.

You do not need coding, Terminal or Git experience. I will explain those as we go. You will need a Mac, an internet connection for setup and the AI, and access to either Claude Code or Codex. Check the chosen tool's account requirements and costs before starting; you do not need both.

1. Pick one small thing to build #

Think about something you do repeatedly at work or at home. Could a small app make it easier? For this walkthrough, we will build a task list with 3 actions: add a task, mark it complete, and delete it.

It will save its data on your Mac, without accounts or syncing. We will use Electron, which lets an app built with web technologies run in a desktop window. You do not need to learn those technologies before trying this.

Follow the task-list example first if you are unsure. Once it works, you can use the same process for your own idea.

Your prompts and your project's code go to the AI provider's servers, so use sample data while building, not anything real. If your idea involves work, check your employer's rules before sharing company information or installing tools on a work computer.

2. Set up your Mac and create a project folder #

Open Terminal from Applications → Utilities. Terminal lets you give your Mac written instructions. In the command boxes below, copy one line at a time into Terminal and press Return. Wait for it to finish before entering the next line.

The command prompt is the line where Terminal waits for your next instruction, often ending in % or $. When it reappears, the command has finished. Some successful commands print nothing at all. Copy only the commands inside each box, not the surrounding backticks or a prompt symbol.

First, check for Git:

git --version

Git saves checkpoints of your code, so you can compare changes and recover an earlier version. If you see a version number, it is installed. If macOS offers to install its Command Line Tools, accept and let that finish. If Git is missing and no prompt appears, run:

xcode-select --install

These are Apple's command-line tools; you do not need the full Xcode app for this walkthrough. Run git --version again after installation.

Next, go to the Node.js download page, choose LTS, and download the macOS installer (.pkg). Open the downloaded file and follow the installer. Node runs the JavaScript development tools; the included npm downloads code packages and runs project commands.

An installer may ask for your Mac login password. If a trusted installation step asks for it inside Terminal, no characters or dots appear while you type. That is normal; type it and press Return. Never paste your password into the AI conversation.

Quit and reopen Terminal, then check:

node --version
npm --version

Both should print version numbers. If a command fails, stop there and search for the exact error message, leaving out any private information. Do not continue through the remaining commands hoping it will resolve itself.

Now create the project folder:

mkdir -p ~/Projects/my-first-app
cd ~/Projects/my-first-app
git init

The first line creates the folders. The second tells Terminal to work inside the app's folder. The third starts a local Git repository, the place Git will keep your code history. Nothing has been uploaded, and you do not need a GitHub account.

To see this folder in Finder, run:

open .

The dot means “the folder I am currently in”. It is empty for now.

Choose one coding assistant #

Use the official Claude Code quickstart or Codex CLI setup guide. CLI means command-line interface, the version you use inside Terminal. Follow that guide's Mac installation instructions, then return here.

In Terminal, run:

cd ~/Projects/my-first-app

Then type either claude or codex and press Return. Follow the sign-in prompts. Once you see the assistant's conversation prompt, you can describe what you want in your own words.

Starting in this folder tells the assistant where to work; it does not itself restrict access to the rest of your Mac. Keep permission checks enabled, read approval requests, and avoid unrestricted access. If a request is unclear, ask what it needs and why before approving it.

For models, start with whatever your tool defaults to. At the time of writing, Codex defaults to Astra, which is fine. If you want to keep costs lower, Sol 5.6 with low reasoning is a good starting point. Claude Code defaults to Sonnet, which works well. At the time of writing I use Opus 4.6, but you do not need to change anything for your first app.

3. Describe the app and set the rules before building #

Copy this into your coding assistant, not a normal Terminal prompt:

I have never coded before. Help me build a small task-list app for my Mac
using Electron. Explain unfamiliar terms briefly and work in small steps.

Use a minimal Electron setup with plain HTML, CSS and JavaScript, loading
local files. No TypeScript, frontend framework or separate development server.
Configure npm start to launch the Electron desktop app directly, without
requiring a separate build command.

The first version should let me add a task, mark it complete and delete it.
Save tasks locally so they survive quitting and reopening the app.
No accounts, cloud services, analytics or extra features.

Before building, explain your plan and the packages you need. Packages are
dependencies: code written by others. Check their official sources, explain
why each is needed, and ask me before installing them.

Create a project instruction file for the tool I am using: CLAUDE.md for
Claude Code or AGENTS.md for Codex. Record these rules:
- Keep work focused on this app. Ask before changing anything outside it.
- Never put passwords, API keys or personal data in the code.
- Create a .gitignore to exclude downloaded packages, generated output,
  credentials and local app data from Git.
- Keep Electron's security protections enabled. Do not load remote content.
- Set up formatting, linting, tests, dependency auditing and secret scanning.
- Run the checks after changes. Fix failures rather than disabling checks.
- Review the code for bugs and security issues before calling it ready.
- Do not commit, publish or deploy anything. I will save Git checkpoints.

Explain the plan first and wait for my approval.

The assistant writes these files for you. The instruction file carries the rules into later sessions; .gitignore tells Git which files to leave out. Neither guarantees safety, but they make your expectations explicit before code or packages arrive.

If the plan includes something you do not understand, ask: “What is that for, and can this first version work without it?”

4. Build the first version and open it #

When you understand and approve the plan, send:

Build the small version we agreed on. Install the approved dependencies,
including Electron, and create the files needed for the desktop window.
Configure the start script in package.json to run electron . so npm start
opens the actual Electron app, not just a web server or a browser tab.
Run the checks and verify the launch command before asking me to try it.
If you cannot verify the window opens, explain what I need to check myself.
Create a README.md with beginner instructions for opening it again tomorrow,
where its task data is saved, and how to quit it. Do not package it for release.

The assistant may ask permission to edit files, download approved packages or run commands. Read those requests as they appear. You do not need to copy its code into files yourself.

npm start runs the command the assistant puts in the project's package.json. Here, that command launches Electron. This plain-JavaScript setup needs no separate npm run build or npm run electron command. The Electron first-app tutorial uses this same launch approach.

When it says the app is ready, open a new Terminal window with Shell → New Window. Leave the assistant in the original window. In the new window, run:

cd ~/Projects/my-first-app
npm start

An app window should open, separate from your web browser. Terminal stays occupied while the app runs; it is not stuck. Keep that window open and do not type more commands into it yet.

Add a made-up task such as “Try my first app”, mark it complete, and add another task to keep. With the app selected, quit using Command-Q. Return to the Terminal window where you ran npm start. If the command prompt has not returned, hold Control and press C to stop the process. This is Control-C, not Command-C, and should be done in the app's Terminal window, not the assistant's.

When the prompt returns, run npm start again. Is the saved task still there?

Nothing opened, or the task disappeared? Return to the assistant and describe exactly what happened. Include the error text if there is any. A useful report is “I added a task, quit with Command-Q, reopened with npm start, and the list was empty.” Ask it to fix that before adding features.

Tomorrow, you can open Terminal and run those same 2 commands. This is a development version; it will not yet be an app you double-click in Applications.

5. Make the checks easy to repeat #

You asked for checks before building. Have the assistant show you what it actually configured, rather than accepting “all done”.

  • Formatting, with a tool such as Prettier, keeps code layout consistent.
  • Linting, with a tool such as ESLint, catches certain mistakes and suspicious code patterns.
  • Tests run examples to check behaviour, including saving and loading tasks.
  • Dependency auditing checks installed packages for known vulnerabilities. npm audit is not a complete security review.
  • Secret scanning looks for accidentally included credentials. It cannot recognise every secret.

Ask:

Put the repeatable checks in package.json, the project's command list.
I should be able to run npm run format to format the code, and npm run
quality to check formatting, lint, tests, dependency audit and secret scanning.
Use real checks, not placeholder commands. Configure any tools they need.

Run both commands now. Explain each result and anything these checks do not
cover. Include tests for empty task text and saving/loading tasks. Keep the
agreed setup: npm start opens Electron without a separate build step.

You do not need to edit package.json yourself. After that, run these in a new Terminal window whenever you want to check the project yourself:

cd ~/Projects/my-first-app
npm run format
npm run quality

These checks should finish and return to the command prompt, rather than keep running in a watch mode. The exact output varies by tool. If you cannot tell whether they passed, copy the output to the assistant and ask it to explain. If a check fails, ask it to fix the underlying issue, then rerun it. Passing checks are useful evidence, but the AI can write incomplete tests too. Keep trying the app yourself.

An extra layer for dependencies #

I use Socket in my build process to help check third-party packages. Its scans look beyond known vulnerability reports for supply-chain risks. The Socket CLI guide explains its scanning tools and install protection.

That is an optional next layer for this walkthrough, not something silently installed by the commands above. Ask the assistant to walk you through the official setup, including any account requirements, before relying on it. From the first build, keep the rule that new packages need an explanation and your approval.

6. Try to break it, then ask for a review #

Try adding an empty task, a long task and several tasks. Mark one complete, delete another, then quit and reopen. Check that the remaining tasks and their completed states are correct.

Next, ask the assistant for a review:

Review this app without modifying files. Include new files as well as changes
to existing files. Look for bugs, unsafe file access, insecure Electron
settings, unnecessary packages, and missing tests. Check that task text is
handled safely and cannot run as code.

Explain findings in plain language, most important first. Tell me what needs
fixing before I use this prototype and what can wait. Do not claim it is
secure just because the automated checks pass.

A fresh conversation or another model can give you a second pass. You can also use Claude to review Codex's work, or the other way round, if you already have both. You do not need another subscription to take this step.

Ask for the important fixes, rerun the checks, and try the app again. Keep using sample data at this stage, especially if your eventual idea involves sensitive information.

7. Save a working checkpoint, then change one thing #

Once the small version works, save it with Git. A commit is a named checkpoint of the code. It is local until you deliberately upload it somewhere, and it is not a backup of the tasks stored inside your app.

First ask the assistant:

Before I make my first commit, review every file Git would include. Check
for credentials, private data and generated files, and run the secret scan.
Confirm the .gitignore works. Explain the files being saved. Do not commit.

After resolving any findings, open a new Terminal window and run:

cd ~/Projects/my-first-app
git status --short
git add .
git --no-pager diff --cached --stat

The first git command lists changed and new files. The second stages the non-ignored changes in this folder, selecting them for the checkpoint. The last command summarises those staged files. Check they match the assistant's explanation; filenames alone do not prove there are no secrets. If anything is unexpected, stop and ask before committing.

Then run:

git commit -m "Build the first working task-list app"

If Git asks who you are, replace the examples below with your own name and email, keeping the quotation marks. These settings apply to this project and become part of its commit history:

git config user.name "Your Name"
git config user.email "[email protected]"

Run the commit command again. A successful commit prints a short identifier and a summary. You now have a checkpoint to compare future changes against. Ask for help before restoring an old version, because some Git recovery commands discard unsaved work.

Choose one improvement next, perhaps editing a task. Ask for it, try it, run the checks, review it, and save another checkpoint. Small changes make it easier to work out what caused a problem.

As you become more confident #

My AI Build Policy goes further, with automated checks for code quality, security, dependencies and releases. Some run during development, others before commits or in GitHub Actions, which runs checks on uploaded code. That kind of setup is sometimes called a harness, meaning tools around the AI that check and constrain its work.

You do not need the whole policy to try your first idea. Start with this small app and repeatable checks, then add stronger automation as you understand what it does. The next step is packaging it into a standalone app you can open from your Applications folder without Terminal. Distributing it to others adds more on top of that, including signing, notarisation and testing installation and updates.

For now, get the task list working and save that first checkpoint. You can keep learning while you build the next part.