How to Build an App with AI: A Beginner's Guide

By Simon O'Connor · Updated 3 July 2026 · 16 min read

If you want to build an app with AI, the first step is not asking Claude, ChatGPT, or any coding tool to "build me an app." That prompt feels exciting, but it gives the AI too little direction and gives you too little control.

The better first step is to describe the app clearly. Who is it for? What problem does it solve? What data does it handle? What is the smallest useful first version? Once those answers are written down, AI becomes much more useful. It can question the plan, suggest a simple architecture, create files, write code, explain changes, and help you test one small piece at a time.

Start with the problem, not the app

Beginners often start with the form of the software: "I need an app." That is understandable, but it skips the thing that matters most. Software is only useful if it improves a real workflow. Before choosing tools, write down the work that happens today.

Use questions like these:

• Who will use this? A researcher, customer, staff member, student, client, or only you?
• What do they do today? Spreadsheet, notebook, paper form, email chain, folder of photos, manual copy-paste, or memory?
• What is painful? Slow entry, duplicated data, missing context, hard search, bad exports, no backup, unclear status, or poor collaboration?
• What would success look like? Faster field notes, cleaner exports, fewer mistakes, a dashboard, a repeatable report, or a project someone else can use?

Imagine a geology PhD student who wants an app for fieldwork. "A geology app" is too vague. A better problem statement is: "I collect rock samples in the field, record GPS coordinates and notes, take photos, then later match those samples to lab results. Right now the data is split across a notebook, phone photos, and spreadsheets. I want one place to record each sample and export clean data for analysis."

That version gives AI something to work with. It names the user, workflow, data, pain, and outcome. Now the assistant can ask sensible questions instead of guessing.

Choose the first shape

The first version of an app does not have to be the final version. It only needs to prove the workflow. For many ideas, the simplest first version is a responsive web app: a browser-based tool with forms, saved records, and exports. For other ideas, a mobile app or PWA makes more sense because the phone is part of the work.

If you are unsure, use this rough guide:

If that decision is still fuzzy, read Web App vs Mobile App first. The key point is not to build the most impressive platform. It is to choose the smallest platform that proves the real workflow.

What a requirements document is

A requirements document is a plain-English description of what the app must do. It is not code. It is not a pitch deck. It is not a vague idea. It is the shared instruction sheet for you, the AI assistant, and any future developer who helps with the project.

A good requirements document answers three questions:

• What are we building? The purpose, users, workflows, and first version.
• What does it need to store? The data records, fields, files, and exports.
• What counts as done? The must-have features and the testable success criteria.

This document protects you from two common AI mistakes. First, it stops the assistant from inventing features you did not ask for. Second, it gives you a way to review the work. When Claude changes code, you can ask whether the change still matches requirements.md.

A requirements document template

Create a new project folder and save this as requirements.md. Fill it in before you ask AI to build anything.

# App Requirements

## App name
Working name:

## One-sentence purpose
This app helps [type of user] do [important job] so they can [desired outcome].

## Target users
- Primary user:
- Secondary users:
- Technical comfort level:
- Devices they will use:

## Current workflow
Today, the user does this by:
1.
2.
3.

The painful parts are:
- 
- 
- 

## Version 1 goal
The first version should let a user:
- 
- 
- 

## Main user actions
The user needs to be able to:
- Create:
- View:
- Update:
- Delete:
- Search/filter:
- Export/report:

## Data to store
Record type:

Fields:
- field_name: what it means, required or optional
- field_name: what it means, required or optional
- field_name: what it means, required or optional

Files or uploads:
- 

## Screens/pages needed
- Home/dashboard:
- Add/edit form:
- Detail page:
- List/search page:
- Export/report page:
- Settings/admin:

## Must-have features for version 1
- 
- 
- 

## Nice-to-have features for later
- 
- 
- 

## Out of scope for version 1
Do not build these yet:
- 
- 
- 

## Privacy and security notes
- What data is private?
- Who should be able to see it?
- Are there API keys, passwords, or sensitive research data?
- Does the app need login for version 1?

## Success criteria
Version 1 is successful when:
- 
- 
-

The most important section is "Out of scope." AI assistants are eager. If you let them, they will happily add maps, logins, admin panels, mobile sync, charts, and ten settings pages before the basic record form works. Writing down what not to build keeps the first version small enough to finish.

Example: GeoSample Tracker

Here is what a filled-in first pass might look like for a fictional geology PhD project. It is not perfect, but it is specific enough for Claude to ask useful questions and propose a sensible version 1 plan.

# App Requirements

## App name
GeoSample Tracker

## One-sentence purpose
This app helps a geology PhD student record field samples, photos, locations, and lab status so field data does not get lost across notebooks, phone photos, and spreadsheets.

## Target users
- Primary user: one geology PhD student
- Secondary users: supervisor may review exported CSV files
- Technical comfort level: beginner developer, comfortable with spreadsheets
- Devices they will use: laptop in the office, phone in the field

## Current workflow
Today, the user does this by:
1. Writing sample IDs and notes in a paper notebook.
2. Taking photos on a phone.
3. Copying sample details into a spreadsheet later.
4. Adding lab results when they arrive.

The painful parts are:
- Photos and notes are separated.
- GPS coordinates are easy to forget.
- Sample status is hard to track.
- Exporting clean data for analysis takes manual cleanup.

## Version 1 goal
The first version should let a user:
- Add a sample record.
- Store sample ID, date, location, notes, rock type, and lab status.
- Search or filter samples.
- Export sample records as CSV.

## Main user actions
The user needs to be able to:
- Create: new sample records
- View: a list of samples and a single sample detail page
- Update: notes, rock type, lab status, and coordinates
- Delete: test records created by mistake
- Search/filter: by sample ID, rock type, field area, and lab status
- Export/report: CSV export for analysis

## Data to store
Record type: Sample

Fields:
- sample_id: unique sample code, required
- collection_date: date collected, required
- field_area: field area or site name, required
- latitude: decimal coordinate, optional for version 1
- longitude: decimal coordinate, optional for version 1
- rock_type: short text label, optional
- notes: longer field notes, optional
- lab_status: not sent, sent, results received, archived
- photo_reference: filename or link to photo, optional for version 1

Files or uploads:
- Photo upload is nice-to-have, not required for version 1.

## Screens/pages needed
- Home/dashboard: count samples by lab status
- Add/edit form: create or update a sample
- Detail page: view one sample
- List/search page: browse and filter records
- Export/report page: download CSV
- Settings/admin: not needed for version 1

## Must-have features for version 1
- Add sample records.
- Edit sample records.
- List and filter samples.
- Export CSV.
- Use fake test data first.

## Nice-to-have features for later
- Photo uploads.
- Map view.
- Offline field mode.
- Login.
- Sync between laptop and phone.

## Out of scope for version 1
Do not build these yet:
- Native mobile app.
- Multi-user accounts.
- Offline sync.
- Automatic GPS capture.
- Photo upload.

## Privacy and security notes
- Early test data should be fake.
- Real field data should not be pasted into public AI tools.
- Login is not required for the local prototype.

## Success criteria
Version 1 is successful when:
- I can add 20 sample records.
- I can edit a record without losing data.
- I can filter by lab status.
- I can export a CSV and open it in Excel or Python.

Notice how modest this is. It does not ask for offline sync, camera capture, map tiles, authentication, and a polished mobile experience on day one. It asks for a useful record system. That is exactly the kind of scope AI can help you build and understand.

Create the project folder

Before opening Claude Code, create a simple folder for the project. The goal is to keep the brief, AI instructions, notes, and future app code together.

mkdir geo-sample-tracker
cd geo-sample-tracker
mkdir notes app

The folder can start like this:

geo-sample-tracker/
  requirements.md
  CLAUDE.md
  notes/
  app/

Save the requirements document at the project root, not inside app/. It describes the whole project, so Claude should see it before touching any code.

Set up Claude Code

Claude Code is Anthropic's coding assistant that runs in a terminal and works inside your project folder. The exact install details can change, so check the official Claude Code quickstart and setup guide if anything below looks different on your machine.

The official docs currently show these install options:

# macOS, Linux, or WSL
curl -fsSL https://claude.ai/install.sh | bash

# Windows PowerShell
irm https://claude.ai/install.ps1 | iex

:: Windows CMD
curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

After installing, open a terminal in your project folder and start Claude Code:

cd path/to/geo-sample-tracker
claude

On first use, Claude Code will prompt you to log in. The official quickstart says Claude Code requires a Claude subscription, a Console account, or supported provider access. If you are setting this up for the first time, follow the browser login flow and then return to the terminal.

Write a useful CLAUDE.md

A CLAUDE.md file is a project instruction file. Claude Code's memory docs describe it as a plain Markdown file that gives Claude persistent context and instructions for a project. In beginner terms, it is the note you leave on the desk before the AI starts work.

Save this as CLAUDE.md in the project root:

# Claude Project Instructions

## Project overview
This project is GeoSample Tracker, a beginner-friendly app for recording geology field samples, notes, coordinates, lab status, and CSV exports.

## Main project documents
- requirements.md is the source of truth for what the app should do.
- notes/ is for planning notes and decisions.
- app/ is where application code should go once we start building.

## Working style
- Read requirements.md before suggesting code.
- Ask clarifying questions when the requirements are vague.
- Build one small feature at a time.
- Explain what files you changed and why.
- Prefer simple, boring technology over complex stacks.
- Do not add features that are listed as out of scope for version 1.

## Safety rules
- Use fake sample data until the app is ready for real data.
- Do not hardcode API keys, passwords, or secrets.
- Do not delete files without asking first.
- Do not introduce a database, framework, or deployment tool without explaining why.

## Version 1 priority
The first version should support:
- Add a sample record.
- Edit a sample record.
- List and filter samples.
- Export records as CSV.

## Before coding
Before writing code, produce:
1. A short summary of the app.
2. Any questions that block a good implementation.
3. A version 1 build plan.
4. The simplest technical architecture you recommend.

Keep this file short. If it grows into pages of instructions, Claude may have trouble separating what matters every session from what only mattered once. Put durable rules in CLAUDE.md. Put temporary ideas in notes/.

First prompts to use

Now you can give Claude the kind of prompt that produces useful planning instead of chaotic code. Save these prompts in notes/first-prompts.md or paste them one at a time into Claude Code.

# First prompts

## 1. Understand the project
Read requirements.md and CLAUDE.md. Do not write code yet. Summarize what this app is for, who will use it, and what version 1 should include.

## 2. Find gaps
Ask me the most important questions that need answering before we choose a technical architecture. Keep the questions practical and beginner-friendly.

## 3. Propose version 1
Turn requirements.md into a version 1 feature list. Separate must-have, nice-to-have, and out-of-scope items.

## 4. Suggest the simplest architecture
Suggest the simplest technical architecture for this project. Explain whether it should start as a script, web app, PWA, or mobile app. Do not write code yet.

## 5. Create a build plan
Create a step-by-step build plan for version 1. Each step should be small enough to test before moving to the next.

## 6. Start with one small feature
Build only the first small feature from the plan. Explain what files you created or changed, then tell me how to run or inspect it.

These prompts slow the process down in a good way. They make Claude inspect, question, plan, and then build. That is much safer than asking for the finished app in one go.

Use Git from the start

Git is a version history tool. You do not need to be a Git expert on day one, but you should use it before AI starts changing files. It gives you a checkpoint you can return to if a generated change breaks the project.

From the project root:

git init
git add requirements.md CLAUDE.md notes
git commit -m "Add project requirements and Claude instructions"

Then, before each new feature, ask Claude:

Before changing files, check git status and tell me what is currently modified.

After each feature works, commit again. A beginner-friendly pattern is: one small feature, run it, inspect it, commit it. That rhythm protects you from losing a working version.

A safe AI-assisted workflow

AI coding tools are strongest when the work is broken into visible steps. You should be able to run, inspect, or explain each step before moving on.

1. Write the requirements. Describe the app before asking for code.
2. Ask for questions. Let Claude find gaps in the requirements.
3. Choose the first shape. Script, web app, PWA, or mobile app.
4. Ask for a build plan. Keep each step small and testable.
5. Build the first feature only. Do not build the whole app at once.
6. Run it yourself. If you cannot run it, the feature is not done.
7. Ask Claude to explain the change. You should understand the files it touched.
8. Commit the working state. Use Git as your save point.
9. Update the requirements. If the plan changes, write the decision down.

This workflow may feel slower than one giant prompt. It is faster in the only way that matters: it keeps the project understandable.

A version 1 build plan

For a small research-data app like GeoSample Tracker, a sensible first plan might look like this:

1. Data model. Define what a sample record contains: sample ID, date, field area, coordinates, rock type, notes, and lab status.
2. Storage decision. Start with a simple local file or SQLite database, depending on how much structure the app needs.
3. First interface. Build the simplest way to add a sample record.
4. List view. Show saved samples in a table.
5. Edit flow. Let the user update a sample without losing existing data.
6. Filtering. Filter by lab status, rock type, or field area.
7. CSV export. Export records for Excel, Python, R, or GIS workflows.
8. Validation. Catch missing sample IDs, invalid dates, and impossible coordinates.
9. Fake-data test. Add 20 fake samples and confirm the workflow holds up.
10. Next decision. Decide whether the next version needs photo upload, map view, login, deployment, or offline support.

That plan is intentionally boring. Boring is good at the start. The first version should prove that the core data workflow works before you spend time on the exciting edges.

What not to do

Here are the mistakes that cause most AI-assisted beginner projects to fall apart.

• Do not ask for the entire app in one prompt. You will get a pile of code with too many decisions hidden inside it.
• Do not skip the requirements document. If the target is vague, the implementation will be vague.
• Do not let AI choose a complex stack without explanation. Ask why each tool is needed.
• Do not start with real private data. Use fake data until the workflow is proven.
• Do not build mobile first just because the word "app" suggests a phone. Many first versions should be web apps or scripts.
• Do not accept code you cannot run. A feature is not real until you can start it, click it, test it, or inspect its output.
• Do not keep changing direction in chat only. Update requirements.md so the project memory stays true.

Where Python fits

Python is a strong first language for this kind of project because it can grow with the idea. A project can start as a script, become a small Flask or FastAPI web app, connect to a database, call external APIs, run tests, and eventually deploy to a public URL.

That path is also easier to understand than jumping straight into native mobile development. Even if the product later becomes an iOS or Android app, the backend still matters. The mobile app will need somewhere to store data, authenticate users, generate exports, send emails, and run business logic. Those are backend skills.

A good learning path after this guide is:

• Web App vs Mobile App, to choose the first product shape.
• Flask vs FastAPI, to choose a first Python web framework.
• Local Hosting vs Deployment, to understand what changes when the app leaves your laptop.
• Deploy a Flask App, to take a simple web app live.
• Storing API Keys Safely with .env, before you add secrets or external services.

Your first Claude session

If you want a single beginner-safe first session, use this:

Read requirements.md and CLAUDE.md.

Do not write code yet.

First, summarize the app in plain English.
Second, list any unclear requirements.
Third, suggest the simplest version 1 architecture.
Fourth, propose a step-by-step build plan where each step can be tested before moving on.

That prompt gives Claude a useful role: not magician, not replacement developer, but careful technical partner. Once the plan is clear, ask it to build one small feature. Then run it. Then commit it. Then move to the next piece.

That is how you start building an app with AI without handing the steering wheel to a machine you do not understand yet.