Learn Cursor

Getting Started

Setting Up Your Laptop

Welcome. You're about to learn how to build software with AI. You don't need a computer science degree, and you don't need prior experience. You need Cursor, a browser, and a few hours. Let's go.

Do a few things before you start — it should take about 10–15 minutes. Nothing complicated — just follow the steps below.

You don't need to understand what any of this means right now. The rest of this guide explains the ideas. For now, just get through the setup so you can open a project and follow along without friction.

⚠️ Use Your Personal Laptop

Please use your personal laptop for this guide — not your company/work laptop. Work machines often have restrictions that block software installations, and we don't want you stuck fighting IT policies when you could be building.

Step 1: Create a GitHub Account

If you don't already have one, sign up at github.com. The free plan is all you need. If you already have an account, you're done with this step.

Again — don't worry about what GitHub is or why you need it. We'll cover that as you work through this guide.

Step 2: Install Cursor

Cursor is an AI-powered code editor. Think of it as your AI pair programmer.

  • Download it from cursor.com
  • Install it and open it
  • A Pro subscription ($20/month) is strongly recommended. The free tier has usage limits that may cut you off mid-session. You can cancel anytime if it's not for you — but we suspect you'll want to keep it. If you'd rather try the free tier first, that's okay — just know there's a chance you'll hit the limit while you're deep in a build.
  • If you already use VS Code, Cursor will offer to import your settings and extensions. Say yes — it makes the switch seamless.

Step 3: Let Cursor Set Up the Rest

This is the fun part — and honestly, your first real lesson before the rest of the guide. You're going to ask an AI to set up your machine for you.

  1. Create a new folder on your laptop wherever you like. Call it something like cursor-practice-project.
  2. Open Cursor, then open that folder (File → Open Folder).
  3. Open the AI chat panel on the right side (press Cmd+L on Mac / Ctrl+L on Windows).
  4. Copy-paste this entire prompt into the chat and hit send:
Prompt

I'm setting up my machine to learn Cursor and build with AI. I need the following installed on this machine:

  1. Git — version control software
  2. Node.js (LTS version) — a JavaScript runtime

Please do the following:

  • Check if each of these is already installed
  • Install whatever is missing
  • After everything is done, run the version check commands and show me the version numbers for git, node, and npm

Important: After you're done with everything, give me a short plain-English summary (2–3 sentences, no jargon) of what you just did and why these tools were needed. I'm new to this, so keep it super simple.

  1. Let the agent work. It will figure out your operating system, run the right terminal commands, and handle everything. If it asks for permission to run a command, say yes.
  2. At the end, you should see version numbers for git, node, and npm, plus a simple summary of what was done. Take a screenshot of this — it's your confirmation that everything is working.

If Something Goes Wrong

Don't panic. Installations sometimes throw errors — that's normal, even for experienced developers.

Your move: Ask the Agent in Cursor to fix the error. It is surprisingly good at it.

Quick Checklist

  • I'm using my personal laptop (not a work machine)
  • GitHub account created
  • Cursor installed (Pro subscription strongly recommended)
  • Cursor's agent installed Git and Node.js for me
  • I have a screenshot showing version numbers for git, node, and npm

That's it. You're ready to keep going.

Introduction to Software Engineering

Who is this section for? If you're a product manager, designer, founder, or anyone who hasn't written code professionally — read this carefully. If you're a developer, skip to Good Coding Practices. You already know all of this.

What you don't need to do: Memorise any of this. This section gives you a mental map so you're not lost when we start building. That's it. Cursor will handle the actual code.

A quick note: Everything in this section (and this guide) is about building for the web — websites and web applications that run in a browser. We're not covering mobile app development (iOS/Android apps you download from the App Store or Play Store). App development is a different stack, significantly more complex to set up, and not what you (usually) need for personal projects and prototyping. The web is where you get the fastest path from idea to something real that anyone can access with just a URL. That's why we're here.

Click on each to know more

The Restaurant AnalogyClient, API, server, database — explained as a restaurant.

This is the single most useful mental model in software engineering. Once you get this, everything else makes sense.

Imagine a restaurant.

You (the customer) are the Client. You sit at a table, you look at a menu, you place an order. You don't walk into the kitchen and cook your own food. You interact with what's in front of you — the table, the menu, the plates. In software, this is the front-end: the website or app you see and interact with. Buttons, forms, pages, colors — that's all front-end.

The Waiter is the API. You tell the waiter what you want. The waiter takes your order to the kitchen and brings back your food. You never talk to the chef directly. In software, the API (Application Programming Interface) is the messenger between the front-end and the back-end. When you click "Sign In" on a website, an API carries your request to the server and brings back the response ("yes, you're logged in" or "wrong password").

The Kitchen is the Server (Back-end). This is where the actual work happens. The chef receives your order, figures out what to do, cooks the food, and hands it back to the waiter. In software, the server runs the logic: processing data, making decisions, running calculations. You never see it as a user, just like you never see the kitchen as a diner.

The Pantry is the Database. The kitchen doesn't conjure ingredients out of thin air. It pulls from the pantry — where all the raw ingredients are stored, organized, and ready to use. In software, the database stores all the data: user accounts, product listings, messages, orders. The server reads from and writes to the database, just like the chef pulls from and restocks the pantry.

The House Rules are Middleware. Before you're seated, the host checks: do you have a reservation? Is there a dress code? Are you old enough to order from the bar? These checks happen between you arriving and you placing an order. In software, middleware handles things like: is this user logged in? Do they have permission to see this page? Is this request legitimate? It sits between the client and the server, filtering and checking.

That's it. That's the architecture of almost every application on the internet:

Client → API → Middleware → Server → Database

Or in restaurant terms:

You → Waiter → House Rules → Kitchen → Pantry

Languages vs. FrameworksLanguages vs frameworks, stacks per layer, what we use Saturday.

Before we talk about frameworks, let's clear up something that confuses everyone at first.

Languages: How You Communicate

A programming language is exactly what it sounds like — a language. It's how you talk to a computer. Just like you'd use English or Hindi or Telugu to communicate with a person, you use Python, JavaScript, or TypeScript to communicate with a machine.

Different languages exist because they're good at different things, just like different natural languages have words and expressions that don't translate perfectly. Python reads almost like English and is great for data, scripts, and back-end logic. JavaScript was built for the web and runs in every browser on the planet. TypeScript is a fancier version of JavaScript with extra safety rails — same language, just stricter. Think of it as JavaScript wearing a seatbelt.

Frameworks: The Pre-Made Base

Here's something every kitchen knows: you don't make every dish from scratch.

Take a tomato. It's a single ingredient — versatile, fundamental, used everywhere. But what you do with that tomato depends on what you're building. An Italian kitchen blends it into a pizza sauce — the base for an entire tradition of dishes. An Indian kitchen cooks it down with onions into a masala gravy — the base for a completely different tradition. Same raw ingredient, two entirely different foundations, two entirely different cuisines.

Software works the same way. A framework is your pre-made base. It's a set of pre-built tools and structures — written in a specific language — that handles the common stuff so you can focus on what's unique to your project.

Here's the key relationship: frameworks are written using languages. The language is the tomato. The framework is the pizza sauce or the masala gravy — a prepared foundation built from that raw ingredient. And just like one ingredient can produce very different bases for very different cuisines, one programming language can have multiple frameworks that serve completely different purposes.

Every Part of the Restaurant Has Its Own Frameworks

Remember our restaurant? Each component — the dining area, the kitchen, the pantry — has frameworks designed specifically for it:

Front-end frameworks (the dining area — what customers see and interact with):

  • React — Built with JavaScript/TypeScript. The most popular front-end framework in the world. Used by Instagram, Netflix, Airbnb.
  • Vue — Also JavaScript. Lighter and simpler. Popular in Asia and Europe.
  • Angular — JavaScript again. Used heavily by large enterprises like Google.

Back-end frameworks (the kitchen — where the logic and processing happens):

  • Django — Built with Python. Great for building things fast. Instagram's back-end started with Django.
  • FastAPI — Also Python. Newer, faster, designed for building APIs specifically.
  • Express — Built with JavaScript/Node.js. Lightweight and flexible.

Database tools (the pantry — where data is stored):

  • PostgreSQL, MySQL — Traditional databases. Think of them as well-organized pantries with labelled shelves and inventory lists.
  • MongoDB — A more flexible database. Think of it as a pantry where you can throw things in without rigid shelf labels.
  • Supabase, Firebase — These are managed database services. Someone else organises and maintains the pantry for you.

Notice how Django and FastAPI are both Python frameworks but serve different purposes — just like the same gravy base can be tweaked for different dishes. Similarly, React, Vue, and Angular are all JavaScript frameworks but take different approaches to building front-ends.

You absolutely do not need to remember any of these names. They're here so that when you hear someone say "I built it in Django" or "it's a React app," you have a rough idea of what layer of the restaurant they're talking about.

What We're Using in This Guide

In this guide, we'll use Next.js. It's a particularly versatile framework — think of it as a base that works for both the dining area and the kitchen. It handles front-end (what users see) and back-end (the server logic) in a single project. It's built on JavaScript/TypeScript, which means you write one language for everything.

The calculator demo at the end of this section is built with Next.js. When you click a button on the calculator (front-end), it sends a request to the server (back-end), the server does the calculation, and sends back the result. You'll be able to open the browser console and actually see these requests and responses happening in real time — the waiter going back and forth between your table and the kitchen.

A Few More Terms You'll See

  • Node.js — You installed this in the setup guide. It lets JavaScript run outside the browser — on servers, on your laptop, anywhere. Without Node, JavaScript could only work inside a web browser. Think of it as the gas supply to the kitchen — the kitchen (your framework) can't run without it.
  • npm — Node Package Manager. The grocery delivery service for your project. When your project needs a tool or library someone else has built, npm fetches it for you.
  • package.json — Your project's shopping list. It lists every dependency (ingredient) your project needs. When you run npm install, npm reads this list and fetches everything.

You'll see these words in your project files as you build. Now they won't scare you.

Your Laptop vs. The World: Development and ProductionLocal vs deployed; dev vs prod; why you don’t edit production live.

Right now, when you write code on your laptop and run it, only you can see it. It's running locally — on your machine, using your machine's resources. If you close your laptop, it stops. Nobody else can access it.

This is actually great for building. Your laptop is your personal test kitchen — experiment freely, taste as you go, mess up a recipe, try again. Nothing you do locally affects anyone else. This is important. You cannot break anything that matters by experimenting on your own laptop.

When you're happy with what you've built and you want others to see it, you deploy it. Deploying means taking your code and running it on a computer somewhere else — a server that's always on, always connected to the internet, and has a public address (a URL) that anyone can visit.

That's all deployment is. Your code, running on someone else's computer, accessible to the world.

Development vs. Production

In the real world, these two environments have names:

Development (dev) — Your laptop. Where you experiment, build, break things, and fix them. Nobody sees this but you. The test kitchen.

Production (prod) — The live server. Where real users visit your site. The restaurant floor during dinner service. This needs to work. Always.

Here's why this distinction matters. Let's say you've built a website and deployed it. 100 people visit it every day. It works beautifully. Now you want to add a new feature — maybe a dark mode toggle.

You do NOT open the live production code and start editing. That would be like remodelling the kitchen while customers are eating dinner. If something goes wrong mid-edit, those 100 daily visitors see a broken site. Or worse, the whole thing crashes.

Instead, you work on your development copy — your laptop. You add the dark mode feature there. You test it. You click around, make sure nothing is broken. You try edge cases. You hate the shade of grey you picked, so you change it. All of this happens safely on your machine while the 100 real users continue using the perfectly working production version.

Only when you're satisfied that the new feature works do you push it to production. The live site updates. Nobody experienced any downtime or bugs. The kitchen remodel happened off-hours.

This is exactly why local and remote exist as separate things — and it's the perfect segue into version control, because version control is how you manage the flow from dev to production without losing your mind.

When you deploy, Vercel is a great default for Next.js projects. It's almost absurdly simple — connect your project, click deploy, get a URL. Your prototype will be live on the internet in under a minute.

Version Control: Save Points for Your CodeGit vs GitHub, push/pull, commits, branches — the basics.

So you're working in development, building features, experimenting. How do you keep track of what's working, what changed, and how to undo something if it breaks?

Here's a mistake I made when I first started building: I didn't use version control. I'd write code for hours, things would work, I'd keep going, break something, try to fix it, break it more, and then realise I couldn't get back to the version that was working. Hours of work, gone. I had no save points. I couldn't go back.

Version control is save points in a video game. You save at a point where things work. If you die (break your code), you reload the save and try again. That's Git.

Git vs. GitHub: Two Different Things

Git is the tool that runs on your laptop. It tracks changes to your files. Every time you "commit," you're creating a save point. Git lives locally — it works even without the internet.

GitHub is a website where you store a copy of your project online. Think of it as cloud storage for your code, but smarter — it keeps track of every save point, lets others see your work, and makes collaboration possible.

Local is your laptop. It's where you write code and make save points (commits).

Remote is GitHub. It's where you store a backup and, eventually, where deployment tools like Vercel pull your code from.

Why Both Exist

You might wonder: why not just work directly on GitHub? Why do I need a local copy?

Same reason a chef doesn't cook in the pantry. You work in the kitchen (local), experiment, taste, adjust. When the dish is ready, you put it on the shelf (remote). If you tried to cook in the pantry, you'd make a mess of the stored ingredients and anyone else trying to access them.

Working locally means you can break things freely without affecting the stored, working version. When you're happy, you push your changes to the remote. If someone else has made changes on the remote, you pull them to your local.

The Commands You'll Use

You don't need to memorise these — Cursor can run them for you. But it helps to know what they mean when you see them:

  • git add . → "Hey Git, I want to save the current state of all my files."
  • git commit -m "added login page" → "Create a save point with this description."
  • git push → "Send my save points to GitHub."
  • git pull → "Get the latest changes from GitHub to my laptop."

The one habit to build: Commit early, commit often. Every time something works — even something small — commit it. A save point every 10–15 minutes is not too often. A save point once in 2 hours is a disaster waiting to happen.

Branches (Quick Mention)

Most beginners work on a single branch called main at first. That's fine.

But in real projects with multiple people, you don't want everyone editing the same branch simultaneously. Imagine five chefs all reaching into the same pot at once — chaos. So developers create branches — separate copies of the code where they can work on a feature without disturbing everyone else. When the feature is done, the branch gets merged back into main.

You don't need to use branches at first unless you want to. But now you know what they are when someone mentions them.

What You Don't Need to Know (Yet)DNS, deep SQL, DevOps — intentionally out of scope for day one.

A few things you might be wondering about that we're deliberately skipping:

  • How the internet actually works (DNS, IP addresses, TCP/IP) — not needed for building a prototype.
  • Databases in detail (SQL, schemas, tables) — if your project needs to store data, Cursor will set it up for you. You just need to know the concept.
  • CSS, HTML in depth — Cursor writes this for you. You'll point and say "make that button bigger" and it will.
  • DevOps, CI/CD, Docker — these are important in professional engineering but completely irrelevant for going from idea to prototype.
  • System design, scaling, performance — you're building for 1 user right now (you). Worry about 1 million users later.

Choosing the Right Tool: What's What in the AI Building Landscape

Before you open Cursor, it's worth understanding that Cursor is not the only tool for building with AI — and it's not always the best one for every job. Different tools are built for different use cases, and picking the right one saves you hours of frustration.

Here's how the landscape breaks down into three broad categories.

Code Editors with AI Agents — Cursor, Claude Code

Full-featured code editors (IDEs) where an AI agent sits alongside you, writing and editing code in real files on your machine. You see every file, every line, every change. You have full control.

Best for
  • Building applications with both front-end and back-end logic
  • Projects where you need fine-grained control over the codebase
  • API integrations, server-side logic, database connections
  • Projects that will grow in complexity over time
  • Working with existing codebases and repos
  • Developers who want to understand and own every piece of their code
Not great for
  • Quick, visually polished landing pages (functional but rarely beautiful)
  • Non-technical users who don't want to see any code at all
  • Simple automations that don't require custom code

Cursor vs. Claude Code — what's the difference?

They're similar in philosophy but different in interface. Cursor is a visual editor (built on VS Code) — you see your files, your folder tree, your terminal, all in a GUI. Claude Code is terminal-first — you interact with it entirely through the command line. Both use AI agents to write and edit code, both support planning and execution workflows.

AI App Builders — Lovable, Bolt (by Replit)

Browser-based tools that generate complete web applications from natural language descriptions. You describe what you want, the tool builds it, and you get a live preview in seconds. You can iterate by describing changes, and the tool updates the app in real time.

Best for
  • Landing pages, portfolio sites, marketing pages
  • Quick prototypes and MVPs where visual polish matters more than back-end complexity
  • Designers who want to see results immediately without a code editor
  • When you need something that *looks* great fast — stronger design sense than Cursor
  • Internal tools with simple forms, dashboards, and CRUD operations
Not great for
  • Complex back-end logic, custom APIs, or sophisticated server-side processing
  • Projects that need deep integration with external services or databases
  • When you need full control over the codebase and deployment infrastructure
  • Projects that will scale to production-grade applications
  • Situations where you want to understand how the code works under the hood

The key distinction: Lovable and Bolt optimize for speed and visual quality. They're incredible at going from "I want a landing page for my chai brand" to a beautiful, deployed site in minutes. But the moment you need something that goes beyond front-end — authentication logic, payment processing, database queries, API rate limiting — you start hitting walls.

Think of it this way: Lovable/Bolt are like ordering from a restaurant. Fast, beautiful, but you eat what's on the menu. Cursor is like having a fully equipped kitchen — slower to start, but you can cook anything.

AI Workflow Automation — n8n, Gumloop

Visual, no-code platforms for building automated workflows. You connect apps, data sources, and AI models using drag-and-drop nodes on a canvas. Instead of writing code, you wire together triggers, actions, and logic blocks.

Best for
  • Automating repetitive business processes (lead scoring, ticket triage, data enrichment)
  • Connecting multiple SaaS tools (Slack → Google Sheets → CRM → Email)
  • Workflows that need AI reasoning — sentiment analysis, content generation, data classification
  • Non-technical teams who want to automate without any code
  • Scheduled tasks, webhooks, and event-driven automations
  • Scraping, processing, and routing data across systems
Not great for
  • Building user-facing applications (websites, web apps, mobile apps)
  • Custom front-end interfaces or interactive UIs
  • Projects that need a codebase, version control, or deployment pipeline
  • Anything that requires a user to visit a URL and interact with something you built

n8n vs. Gumloop — what's the difference?

n8n is the more established, open-source option with a massive integration library (1000+ connectors). It's self-hostable, which makes it popular with developers and privacy-conscious teams. Gumloop is newer, AI-native from the ground up, and positions itself as the "AI agent platform" rather than just a workflow tool. Gumloop's visual builder includes AI reasoning nodes natively — every step can use an LLM — while n8n added AI capabilities on top of its existing automation framework. Gumloop is easier to start with; n8n is more powerful for complex, custom automations.

So Which Tool Should You Use?

I want to...Use this
Build a full application with front-end and back-endCursor or Claude Code
Build a beautiful landing page or portfolio fastLovable or Bolt
Automate a business workflow (no UI needed)n8n or Gumloop
Prototype an idea quickly to see if it worksLovable for visual, Cursor for functional
Connect Slack + Sheets + CRM + AI togethern8n or Gumloop
Build something I'll maintain and grow long-termCursor or Claude Code

Good Coding Practices (& Common Mistakes That Will Make You Cry)

Who is this for? Everyone. Developers already know most of this but might pick up a thing or two. If you're new to coding, this section will save you hours of pain. Read it before you start building.

1. The .env File — Your Secrets DrawerKeep API keys out of source; use environment variables.

What it is

A .env file is a simple text file that stores sensitive information your project needs to run — API keys, database passwords, secret tokens. It lives in the root of your project and looks like this:

code
OPENAI_API_KEY=sk-abc123xyz789
DATABASE_URL=postgres://user:password@localhost:5432/mydb
NEXT_PUBLIC_SITE_URL=http://localhost:3000

Why it matters

These are credentials. They're like your house keys, your bank PIN, and your email password — all sitting in a plain text file. If someone gets access to them, they can use your API accounts (and rack up charges on your credit card), access your database, or impersonate your app.

The mistake people make

They put API keys directly in their code:

code
// ❌ NEVER DO THIS
const apiKey = "sk-abc123xyz789";

This means the key is visible in every file, and worse — when you push your code to GitHub, it's visible to the entire internet. Bots actively scan public GitHub repos for leaked API keys. You will get compromised. It's not a matter of if.

What to do instead

Put secrets in .env and reference them in your code:

code
// ✅ DO THIS
const apiKey = process.env.OPENAI_API_KEY;

Now your code just says "get the key from the environment." The actual key lives in .env, which you never push to GitHub (more on that next).

2. The .gitignore File — What NOT to UploadNever commit .env, node_modules, or build output.

What it is

A .gitignore file tells Git which files and folders to ignore when you commit. Anything listed in .gitignore will not be tracked, committed, or pushed to GitHub. It lives in the root of your project and looks like this:

code
node_modules/
.env
.env.local
.DS_Store
dist/
.next/

Why it matters

There are things in your project folder that should never leave your laptop:

  • .env — Your secrets. We just covered this. Never push it.
  • node_modules/ — The folder where npm installs all your dependencies. It can be hundreds of megabytes and contain tens of thousands of files. It's regenerated from package.json whenever anyone runs npm install, so there's no reason to upload it. Pushing node_modules to GitHub is like shipping the entire grocery store instead of just the shopping list.
  • .DS_Store — A hidden Mac file that tracks folder display settings. Useless, clutters your repo.
  • dist/ or .next/ — Built/compiled output. Generated from your source code, not the source code itself.

The mistake people make

They either don't have a .gitignore (so everything gets pushed) or they add .gitignore after they've already committed sensitive files. Here's the thing: Git has a memory. Even if you add .env to .gitignore after you've already committed it once, the old commit still contains your secrets in the Git history. Someone can go back through your commits and find them.

What to do instead

Set up .gitignore as the very first thing when creating a new project — before you write any code, before you add any secrets. Most frameworks generate a sensible .gitignore by default, but always double-check that .env is in there.

3. Committing: The Art of When to SaveCommit when a unit of work works; avoid noisy history.

The mistake: not committing enough

This is the most common beginner mistake, and it's the one that hurts the most. You code for two hours straight. Everything is working beautifully. You make one more change. Something breaks. You try to undo it. You can't remember what you changed. You try to fix it. Now three things are broken. There's no save point to go back to. Two hours of work, gone.

The other mistake: committing too much noise

On the flip side, committing after every single line change creates a history that looks like:

code
"fixed typo"
"fixed another typo"  
"actually fixed it this time"
"why isn't this working"
"okay now it works"
"no it doesn't"
"FINALLY"

This isn't useful to anyone — including future you.

The right rhythm

Commit when a unit of work is complete. A "unit of work" is the smallest change that makes sense on its own. Some examples:

  • ✅ "Added login form with email and password fields"
  • ✅ "Connected weather API and displaying current temperature"
  • ✅ "Fixed bug where form submitted without validation"
  • ✅ "Set up project scaffolding and initial folder structure"

A good rule of thumb: commit every time something works that didn't work before. If you just got the login form to render, commit. If you just hooked up the API and data is flowing, commit. If you just fixed a bug, commit. You're creating a trail of breadcrumbs you can follow back.

For solo developers vs. teams

Solo: You're the only one working on the code, so your commit rhythm is for your own safety. Commit to your local often. Push to remote (GitHub) at the end of a working session or when you've completed a meaningful chunk. There's less urgency to push constantly because nobody else is waiting for your changes.

Teams: Push to remote frequently because others depend on your changes. Pull from remote before starting work each day so you have the latest code. Commit and push at least once per meaningful feature — don't go dark for three days and then push a massive dump of changes. Your teammates will not be happy.

When to raise a PR

A Pull Request should represent a complete feature or fix. Not half a feature. Not "I'm done for the day." A PR says: "This thing works, I've tested it, it's ready to be merged into the main codebase." For solo projects while you're learning, you probably won't need PRs — just commit and push to main. But it's good to know the concept for when you work with others.

4. Folder Structure — Don't Throw Everything in One PileOrganize by concern so you and Cursor stay sane.

The mistake

Your project looks like this:

code
my-project/
├── index.js
├── app.js
├── server.js
├── login.js
├── signup.js
├── dashboard.js
├── api.js
├── helpers.js
├── utils.js
├── styles.css
├── more-styles.css
├── test.js
├── data.json
├── old-backup.js
├── old-backup-2.js
└── TODO.txt

15 files in the root. No folders. No organization. You spend more time finding files than editing them. And when Cursor's agent looks at this project, it has no structural clues about what goes where — so it starts creating files in random places too, and the mess compounds.

What to do instead

Organize by concern. A typical Next.js project should look something like:

code
my-project/
├── src/
│   ├── app/              ← Pages and routing
│   │   ├── page.tsx
│   │   ├── layout.tsx
│   │   └── dashboard/
│   │       └── page.tsx
│   ├── components/       ← Reusable UI pieces
│   │   ├── Button.tsx
│   │   ├── Navbar.tsx
│   │   └── LoginForm.tsx
│   ├── lib/              ← Utility functions & helpers
│   │   ├── api.ts
│   │   └── utils.ts
│   └── styles/           ← Stylesheets
│       └── globals.css
├── public/               ← Static files (images, icons)
├── .env                  ← Secrets (not committed)
├── .gitignore
├── package.json
└── README.md

You don't need to memorize this. The boilerplate repos for the projects below already have this structure set up. The point is: when you ask Cursor to create a new component, it should know where to put it. Good structure gives the AI (and you) clear conventions.

5. Documentation — Your Future Self Will Thank YouREADME, brief, comments on non-obvious logic.

The mistake

You build something. It works. You move on. Three weeks later, you come back to add a feature. You open the project and think: "What the hell does any of this do?"

This is bad enough for you. It's even worse for Cursor. Every time you start a new Cursor session or a new agent is spawned, it has zero memory of what happened before. It looks at your codebase fresh. If there's no documentation, the agent has to infer everything from the code itself — which burns tokens, takes longer, and produces worse results because it's guessing at your intent.

What to document

README.md — Every project should have one. It should answer: What is this project? How do I run it? What's the folder structure? What are the key technologies used? This is the first thing both humans and AI agents read when they encounter your project.

Project brief / PRD — A short document (even just a few paragraphs) that describes what you're building, who it's for, and what the key features are. This is gold for Cursor's planning mode — when the agent has a clear project brief, it makes dramatically better decisions about architecture and implementation.

Inline comments for tricky logic — If you've written (or Cursor has written) something non-obvious, add a comment explaining why, not what. The code shows what's happening; the comment explains the reasoning.

What NOT to document

Don't over-document. You don't need a comment on every line. You don't need a 10-page architecture doc for a personal project. A good README, a short project brief, and comments on the non-obvious stuff — that's the sweet spot.

Exercise: Investigate the Calculator App

Time to get your hands dirty. We've built a simple calculator app for you to explore. This is not a "build from scratch" exercise — the app is already built. Your job is to investigate it, understand how it works, and make a small change.

Clone the calculator repo and follow the instructions in the README:

👉 github.com/kupsas/learn-cursor-s0-calculator

The README has everything you need — setup steps, investigation prompts for Cursor's Ask mode, and suggestions for your first code change. When you've made a change and it works, commit it. That's your first real act of software engineering.