Most people who try building an app with AI do the same thing. They open a tool, type "build me an app that does X," and get excited when something appears on screen. Then they try to change one thing and the whole thing breaks.
That's prompt roulette. Random inputs, random outputs, no system.
The people who actually ship working apps do something different. They create two simple documents before they write a single prompt. Those documents give the AI the context it needs to build something real, and they keep it on track as the project grows.
This guide shows you exactly how to set up your tools, create those documents, build features, debug problems, deploy to the internet, and maintain what you've built. The full lifecycle, not just the fun part.
1 Get Set Up (Before You Build Anything)
Before you write a single prompt, you need the right tool installed and a project folder ready. This takes about 15 minutes.
What Tool Should You Use?
This guide uses Claude Code, a command-line tool from Anthropic that lets you build apps by talking to an AI in your terminal. It reads your files, writes code, runs commands, and manages your project.
The principles in this guide (PRD, project instructions, one feature at a time) work with any AI coding tool: Cursor, Windsurf, Bolt, Lovable, Replit. The specific prompts and file names are written for Claude Code, but you can adapt them.
Why Claude Code specifically? It works directly with your files on your computer. There's no "export" step, no vendor lock-in, and the AI can see and modify everything in your project, not just the file you have open.
What You Need to Install
- Node.js – Go to nodejs.org, download the LTS version, and install it. This is required for Claude Code to run. (Click "Next" through everything, defaults are fine.)
- Claude Code – Open your terminal (search "Terminal" on Mac or "Command Prompt" on Windows), then type:
npm install -g @anthropic-ai/claude-code - A code editor (optional but recommended) – VS Code is free and works great. Download from code.visualstudio.com. This lets you see your files and preview your app while building.
Install Node.js
Download from nodejs.org. Pick the "LTS" version. Install it like any other program. When it's done, open your terminal and type node --version to confirm it worked. You should see a version number.
Install Claude Code
In your terminal, type npm install -g @anthropic-ai/claude-code and press Enter. It'll take a minute to download. When it's done, type claude to start it. It will ask you to log in with your Anthropic account.
Create your project folder
Create a folder on your computer for your project. Something like my-app on your Desktop. In the terminal, navigate to that folder: cd ~/Desktop/my-app. Then type claude to start a session in that folder.
Verify it works
Once Claude Code is running, type "Hello, can you create a test file called hello.txt with 'it works' inside?" If a file appears in your project folder, you're ready to build.
What This Costs
Building with AI isn't free. Here's what to budget so there are no surprises.
| What | Cost | Notes |
|---|---|---|
| Claude Code | ~$20/mo | Included with Claude Pro subscription. Max plan ($100/mo) gets more usage. |
| Hosting | $0–20/mo | Vercel and Railway have free tiers. Most simple apps cost under $10/mo. |
| Database | $0–15/mo | Most platforms include a free database. You won't pay until you scale. |
| Domain name | $10–15/yr | Optional. You get a free URL from your hosting platform. |
| APIs | Varies | Stripe: 2.9% + 30¢ per transaction. SendGrid: free up to 100 emails/day. |
"Terminal" Sounds Scary. It's Not.
The terminal is just a text-based way to talk to your computer. Instead of clicking buttons, you type commands. With Claude Code, you're mostly just typing plain English and letting the AI handle the technical commands.
You'll use three commands over and over:
cd [folder]– Go to a folder. Like double-clicking a folder, but with text.claude– Start Claude Code. That's it. One word.ls– List the files in your current folder. (Usediron Windows.)
Everything else, the AI handles for you.
2 The Two Documents That Change Everything
Before you write a single prompt, you need a PRD and a project instructions file. Here's what they are and why they matter.
Document 1: The PRD WHAT YOU'RE BUILDING
PRD stands for Product Requirements Document. Don't let the name intimidate you. It's just a plain-English description of what your app does, who it's for, and what "done" looks like.
Think of it as a brain dump with structure. You're not writing code. You're describing your business problem and what the solution should do. The AI reads this document and suddenly understands the full picture instead of guessing from one vague prompt.
Think of it like this: if you hired a contractor to renovate your kitchen, you wouldn't just say "make it nice." You'd tell them the layout, the appliances, the budget, what you want to keep and what needs to go. A PRD does the same thing for your app.
Document 2: The Project Instructions File HOW TO BUILD IT
Tools like Claude Code use a special file (called CLAUDE.md) that the AI reads automatically every time you start a session. It's like giving the AI a cheat sheet for your project.
This file contains the rules of the road: what technology you're using, how the project is organized, what patterns to follow, and what mistakes to avoid. Without it, the AI starts from scratch every single time you open a new session. With it, the AI picks up right where you left off.
The best part: you don't have to write this from scratch. You can ask the AI to generate it for you based on your PRD.
Think of it like training a new employee. Instead of re-explaining everything every morning, you give them a handbook. The project instructions file is that handbook for your AI.
Persistent Memory
The AI remembers your project structure, decisions, and patterns across every session.
Consistent Output
Every prompt builds on the same foundation instead of reinventing the wheel.
Safe to Iterate
You can add features without breaking what already works because the AI knows the rules.
3 Create Your PRD (with AI)
You don't need to write this from scratch. Use this prompt to have the AI interview you and build it together.
Interview me one question at a time. Start with the basics, but also ask me about things I probably haven't thought of:
- What problem does this app solve?
- Who uses it? (just me, my team, my customers?)
- If multiple user types, what should each one see vs. not see?
- Walk me through what a user does step by step
- What happens when something goes wrong? (failed payment, duplicate entry, user makes a mistake)
- What other systems does it need to connect to?
- How do you expect to make money from this, or how does it save money?
- What does "done" look like?
- What should this NOT do? (scope boundaries)
Push back on vague answers. If I say "it manages clients," ask me what "manage" specifically means. If I say "users can see their data," ask me what data and in what format.
Based on your experience, also flag things I'm likely overlooking: edge cases, permissions, what happens when the app has 100 users vs. 5, data I'll wish I'd captured from the start, and anything that will be painful to add later.
After we go through these questions, organize my answers into a clean PRD document and save it as PRD.md in the project folder.
What a Good PRD Covers
- The problem: What manual process or pain point does this app eliminate?
- The users: Who logs in? What can each type of user see and do?
- The core workflow: The one thing this app must do, end to end, before anything else gets added
- What "done" means: A specific, walkable sequence from login to completed task
- What's out of scope: What you're deliberately NOT building (this is just as important)
- External connections: What other tools does this need to talk to? (payments, email, CRM, etc.)
PRD Red Flags (Fix These Before Building)
- "Users can manage their stuff" – Too vague. What stuff? Manage how? (edit, delete, share?)
- No error handling mentioned – What happens when a payment fails? When someone enters bad data?
- No user types defined – Even if it's "just me," document that. It'll change.
- Missing "what's NOT included" – Scope creep kills projects. Draw the line early.
4 Generate Your Project Instructions File
Once your PRD exists, ask the AI to create the project instructions file. This takes 30 seconds and saves you hours.
1. A short summary of what this app does
2. The tech stack we're using
3. The project folder structure
4. Important rules to follow (how data should be stored, what patterns to use, security requirements)
5. A list of the features to build, in order
6. Common mistakes to avoid
This file should be the single source of truth for how this project works. Any AI session that opens this project should read this file first and follow these rules.
Keep It Updated
Here's what most people miss: this file should evolve as you build. Every time you make a significant decision (changed the database structure, added a new feature, decided against something), tell the AI to update the project instructions file.
What Belongs in CLAUDE.md
- Project summary: One paragraph explaining what this app does
- Tech stack: What framework, database, hosting (the AI picked these, document them)
- Folder structure: Where different types of files live
- Patterns to follow: "Always use this format for API endpoints," "Store dates in UTC"
- Features list: What's built, what's in progress, what's next
- Environment variables: What keys/secrets the app needs (not the values, just the names)
- Known issues: Bugs you're aware of, workarounds in place
5 See How Your Data Flows
You don't need to understand databases. But you do need to understand what information your app tracks and how it connects.
Every app is really just information moving around. A customer places an order. That order has line items. Those line items have prices. The prices add up to a total. The total gets charged to a payment method. That's data flowing through your app.
You don't need to design this yourself. But you should be able to see it and verify it makes sense.
After you create the database tables, explain the data model back to me in plain English:
For each type of information (users, orders, products, etc.):
1. What information do we store?
2. How does it connect to the other types?
3. What happens to it when a user performs the main workflow?
Use a real example: "When a customer places an order, here's what happens to the data step by step..."
I need to understand this before we build any screens.
Without this step
You build screens that look right, but the data behind them is wrong. Customers see other customers' orders. Totals don't add up. Deleting one thing breaks three other things.
You don't find out until real people use it.
With this step
You verify the data model matches your actual business logic before any code is written. When the AI explains "a Customer has many Orders, and each Order has many Line Items," you can say "yes, that's right" or "no, one order can only have one product."
You catch problems in minutes instead of weeks.
6 How to Prompt for Features (Without Breaking Things)
Setup is done. Now you're building features. Here's how to ask for changes without destabilizing your app.
The Golden Rule: One Thing at a Time
The #1 mistake people make is asking for too much at once. "Add a dashboard with charts, user settings, email notifications, and a dark mode" is a recipe for disaster. The AI will try to do all of it, get confused, and break something.
Instead: Ask for one feature. Test it. Then ask for the next.
Bad Prompt
"Add user authentication, a dashboard, the ability to create projects, invite team members, and send notifications when something changes."
Too much. AI will make mistakes.
Good Prompt
"Add user authentication. Users should be able to sign up with email and password, log in, and log out. Show a simple 'Welcome, [name]' message after login."
One thing. Clear success criteria.
What it should do:
- [Specific behavior 1]
- [Specific behavior 2]
- [Specific behavior 3]
What it should NOT do:
- [Boundary 1]
- [Boundary 2]
How I'll know it works:
- [Test scenario: "When I click X, I should see Y"]
Don't change anything else. Just add this feature.
Prompting Patterns That Work
- "Don't change anything else" – Explicitly tell the AI to leave existing code alone
- "Show me what you're going to change first" – Review the plan before it executes
- "Test this by..." – Give the AI a way to verify its own work
- "If you're unsure, ask me" – Permission to pause instead of guessing
- "Update CLAUDE.md after this change" – Keep the handbook current
7 Connect to the Tools You Already Use
Your app isn't useful if it exists on an island. Here's how to connect it to Stripe, QuickBooks, your CRM, or any other system your business runs on.
Most business tools have something called an API, which is just a way for software to talk to other software. Stripe has one. QuickBooks has one. Google Calendar, HubSpot, Mailchimp, Shopify. They all have APIs. And the AI knows how to connect to all of them.
Tell the AI what you want connected
"When a customer pays in my app, I want it to create an invoice in QuickBooks automatically." That's all you need to say.
Get an API key from the service
Every service gives you a unique key (like a password) that lets your app talk to it. The AI will tell you exactly where to find it and how to set it up.
The AI builds the connection
Once you have the API key, the AI writes all the code to connect the two systems. You don't need to understand the code. You just need to test that it works.
Test with real data
Run through the workflow manually. Place a test order. Check that the invoice shows up in QuickBooks. If something's off, tell the AI what happened and it fixes it.
When [TRIGGER EVENT in my app], it should [ACTION in the external service].
Tell me:
1. What API key or credentials I need and where to get them
2. How to store them securely (in the .env file)
3. How to test this without affecting real data
Build the connection and show me how to verify it works.
Common Integrations (and what to ask for)
- Payments (Stripe): "Charge a credit card when a customer completes checkout"
- Accounting (QuickBooks): "Create an invoice in QuickBooks when an order is placed"
- Email (SendGrid/Mailchimp): "Send a confirmation email when a customer signs up"
- CRM (HubSpot/Salesforce): "Create a new contact when someone fills out my form"
- Calendar (Google): "Add an event to my Google Calendar when a meeting is booked"
- File Storage (AWS/Cloudflare): "Let users upload documents and store them securely"
8 When Things Break (Debugging for Non-Developers)
Things will break. That's normal. Here's exactly what to do when you see an error, a blank screen, or something that doesn't work right.
The 3 Types of Problems You'll Hit
- Red error message: Something crashed. The app shows an error or won't load at all.
- Wrong behavior: The app loads but does something different than you expected.
- Nothing happens: You click a button and nothing changes. No error, no result.
[PASTE THE EXACT ERROR MESSAGE HERE]
This happened when I tried to:
[DESCRIBE WHAT YOU WERE DOING]
What's wrong and how do we fix it?
What I did:
[Step by step what you clicked/entered]
What I expected:
[What should have happened]
What actually happened:
[What you saw instead]
Can you trace through the code and show me where the logic is wrong?
Walk me through what SHOULD happen when that button is clicked, then add some logging so we can see where it stops working.
When to Undo Instead of Fix
Sometimes the fastest fix is to go back to when it worked:
- See what changed: "Show me everything that changed since the last working version"
- Undo the last change: "Revert the last commit"
- Start fresh on this feature: "Undo everything we did today and let's try a different approach"
9 Save Your Work (Git for Non-Developers)
Git is like "save points" in a video game. You can always go back to a working version if something breaks.
Why This Matters
Without version control, when something breaks, you're stuck. You can't see what changed. You can't undo the mistake. With Git, you can always say "take me back to yesterday when it worked" and instantly restore your app.
Think of it like track changes in Word, but for your entire project. Every save point is documented, and you can jump back to any of them.
After every working feature: Save it
When something works, tell the AI to commit it. This creates a save point you can return to.
When something breaks: See what changed
Ask the AI what's different between now and the last save point. The bug is usually in what changed.
When you're stuck: Go back
Undo the recent changes and try a different approach. No progress lost, no panic.
Git Commands Translated
- Commit: A save point with a description
- Push: Upload your save points to the cloud (backup)
- Pull: Download the latest version from the cloud
- Revert: Undo a specific change
- Branch: A separate copy where you can experiment without affecting the main version
- Merge: Combine your experiment back into the main version
10 Protect Your App (Security Basics)
If your app handles customer data, payments, or logins, you need to get security right. Most of it is simple habits, not rocket science.
The .env File: Your App's Secrets CRITICAL
Your app needs passwords to talk to other services: a Stripe API key, a database password, an email service token. These are called environment variables, and they live in a special file called .env.
This file stays on your computer (or server). It never gets shared, uploaded, or committed to Git. If someone gets your .env file, they have the keys to everything your app connects to.
- Never commit .env to Git. The AI should add it to
.gitignoreautomatically. Verify this. - Never paste API keys into chat, email, or Slack. If you need to share them, use a password manager.
- Use different keys for testing and production. Your Stripe test key and live key should be different.
1. Is there a .env file? Is it in .gitignore?
2. Are any API keys or passwords hardcoded in the source code? (They should ONLY be in .env)
3. Is there a .env.example file that shows what variables are needed WITHOUT the actual values?
4. Are passwords hashed, not stored in plain text?
5. Can User A access User B's data? (Check permission boundaries)
Fix anything that's wrong.
The Security Checklist
- .env is in .gitignore – Secrets never go to GitHub
- No hardcoded keys in code – All secrets come from environment variables
- .env.example exists – So you remember what variables are needed
- Passwords are hashed – Never stored as plain text
- Users can only see their own data – Test this explicitly
- HTTPS is enabled in production – Your hosting platform usually handles this
- Input is validated – The app rejects garbage data instead of saving it
11 Test Before You Ship
Before you show your app to anyone, verify it actually works.
The Non-Developer's Testing Checklist
- Happy path: Does the main workflow work when everything goes right?
- Empty states: What does a brand new user see? (no data yet)
- Bad input: What happens if someone enters garbage?
- Permissions: Can users only see their own data?
- Edge cases: Really long text? Really large numbers? Zero items?
- Mobile: Does it work on a phone? Resize your browser to check.
1. The main workflow (happy path)
2. What happens with bad or missing input
3. Edge cases based on the business logic
4. Permission checks (who can see/do what)
For each test, tell me what to do step by step, what I should see if it's working, and what might go wrong.
Testing Integrations
For any external service, always test in "test mode" first:
- Stripe: Use test card numbers (4242 4242 4242 4242). No real money moves.
- Email: Send to yourself first. Check spam folders.
- Calendar: Use a test calendar, not your real one.
12 Put It on the Internet (Deployment)
Your app works on your computer. Now it needs to work on the internet so other people can use it.
What "Deployment" Actually Means
Right now your app only runs on your laptop. When you close the terminal, it stops. Deployment means putting your app on a server (someone else's computer that's always on) so anyone with the link can use it 24/7.
It's like the difference between cooking dinner at home vs. opening a restaurant. The food is the same, but now other people can show up and order it.
Where to Deploy (Pick One)
- Vercel – Best for web apps with a frontend. Free tier is generous. Deploys automatically from GitHub.
- Railway – Best for apps with a database. Simple setup, $5/mo after free trial.
- Render – Similar to Railway. Free tier for simple apps, paid plans for databases.
- Fly.io – Good for apps that need to be fast globally. Slightly more technical.
Can't decide? Start with Vercel if your app is mostly frontend. Start with Railway if it has a database and backend logic.
Push your code to GitHub
Your code needs to live online so the hosting platform can access it. Ask the AI: "Set up a GitHub repository for this project and push the code."
Connect your hosting platform
Sign up for Vercel/Railway (use "Sign up with GitHub" for easiest setup). Connect it to your repository.
Set your environment variables
Remember the .env file? Those secrets need to be set on the hosting platform too. Every platform has an "Environment Variables" section in settings.
Deploy and test
Click "Deploy." Wait 2-3 minutes. You'll get a URL. Open it. Test the main workflow. If something doesn't work, it's usually a missing environment variable.
1. Set up a GitHub repository and push all my code
2. Tell me which hosting platform is best for this app and why
3. List every environment variable I need to set on the hosting platform
4. Walk me through the deployment step by step
After it's live, help me test that everything works on the live URL the same way it works locally.
13 After You Launch (Keeping It Running)
Launching is not the finish line. Real users will find bugs you never imagined, and your app needs care to keep running smoothly.
The First Week After Launch
Expect things to break. Not because you did something wrong, but because real users do things you didn't predict. Someone will put an emoji in a phone number field. Someone will click the submit button 47 times.
- Check your app daily for the first week. Log in, run through the main workflow, look for anything weird.
- Have a way for users to report problems. Even a simple "email me if something breaks" link in the footer.
- Fix bugs fast. Early users are forgiving if you respond quickly.
Ongoing Maintenance (Monthly)
- Database backups: Ask the AI to set up automatic backups. Most hosting platforms do this, but verify.
- Monitor uptime: Use a free service like UptimeRobot to get an alert if your app goes down.
- Update dependencies: Once a month, ask the AI: "Are there any security updates we should apply?"
- Review costs: Check your hosting and API bills monthly. Make sure nothing is spiking.
1. Are database backups configured? If not, set them up.
2. How do I know if the app goes down? Set up a health check endpoint.
3. Are there any outdated packages with known security issues? Update them.
4. Add a simple error logging system so I can see when users hit problems.
Adding Features After Launch
- Update the PRD first. Add the new feature to the document before building it.
- Use a branch. Ask the AI: "Create a new branch for this feature." Build without affecting the live app.
- Test on a staging URL. Most platforms let you preview changes before they go live.
- Deploy the feature. When it works on staging, merge to main and it goes live automatically.
14 The Full Workflow (Start to Finish)
Here's the complete process from idea to live, maintained app. Follow this order. Don't skip steps.
Set up your tools
Install Node.js, Claude Code, and VS Code. Create your project folder. Verify it works.
Create your PRD
Ask the AI to interview you. Describe the problem, users, core workflow, and what "done" means. Save as PRD.md.
Generate project instructions
AI reads your PRD and creates CLAUDE.md with tech stack, structure, rules, and build order.
Build the data layer first
Set up the database. Review the data model in plain English. Make sure it matches your business.
Build the core workflow
The one thing your app must do. End to end. With real data. Commit when it works.
Add features one at a time
One feature per session. Test it. Commit it. Update CLAUDE.md after each major addition.
Add integrations one at a time
Connect to Stripe, QuickBooks, etc. Test each one. Commit when it works.
Run the security checklist
Verify .env is protected, no hardcoded secrets, passwords hashed, permissions tested.
Test everything
Walk through your checklist. Have someone else try it. Fix what confuses them.
Deploy to the internet
Push to GitHub, connect hosting, set environment variables, deploy. Test the live URL.
Monitor and maintain
Set up uptime monitoring and backups. Check in monthly. Keep iterating on user feedback.
Your Checklist
- I have Claude Code installed and working in my project folder
- I can describe what my app does in one sentence
- I've created a PRD with the AI (problem, users, core workflow, scope, integrations)
- I've generated a project instructions file (CLAUDE.md) from my PRD
- The AI has set up my database and I've reviewed the data model in plain English
- The core workflow works end to end with real data (not just screens)
- I'm committing after every feature that works
- I've added integrations one at a time and tested each one
- I've run the security checklist (no hardcoded secrets, permissions tested)
- I'm updating CLAUDE.md after every major change
- I know how to debug (paste the error, describe expected vs. actual)
- Someone else has used the app and I've fixed what confused them
- The app is deployed and working on a live URL
- I have monitoring and backups set up
- I understand the monthly costs and have reviewed them
When This Approach Stops Working
This guide gets you from zero to a real, working app. But there are situations where the "build it yourself with AI" approach hits a wall:
- You need compliance (HIPAA for healthcare, PCI for payments, SOC 2 for enterprise). These require specific security architecture that's risky to get wrong.
- Multiple people need to work on the code. Once you need a team, you need code reviews, architecture decisions, and coordination that AI alone can't manage.
- Performance at scale. 50 users and 50,000 users are different engineering problems. What works for a prototype can fall apart under real load.
- You're spending more time debugging than building. If every new feature breaks two old ones, the codebase needs an architect, not more prompts.
- You're building the wrong thing. The hardest problem isn't code. It's knowing what to build and in what order. That's strategy, not engineering.
Hitting one of these doesn't mean you failed. It means you've outgrown the prototype phase, which is the goal. You now have a working product, real user feedback, and clarity on what needs to be built properly. That's a massive head start.
Ready to Build?
You now have the complete framework, from setup to deployment to maintenance. Start with the PRD prompt above and go.
If you want a 25-year software architect in your corner to guide the process, catch mistakes before they cost you, and get you from idea to launched app in 60 days, let's talk.
Book a Free Discovery Call15 minutes. No pitch. I'll tell you honestly if your app idea is realistic and where to start.