Cursor is an AI-first code editor that lets you build software by typing English instructions instead of code — and despite being designed for engineers, it’s the best entry point I’ve found for non-developer founders who want to ship working things. Last Tuesday I shipped a 200-line script that pulls Stripe payments, dedupes them against my newsletter export, and posts a summary to Slack. Total time: 35 minutes. Total lines of code I personally typed: zero.
I’m a 10-year founder. I have 4 years deep in AI. I can read code and understand the shape of it, but I can’t write JavaScript from a blank file. That used to be a problem. It isn’t anymore. The point of this article is to show you the exact setup, the rules I run, and the five things I had to learn the hard way so you don’t have to.
If you’ve read my Claude Code first 30 days, this article is the parallel for the visual editor side. Cursor and Claude Code aren’t competitors. They’re two halves of the same workflow.
What is Cursor, in one paragraph?
Cursor is a fork of VS Code with Claude Sonnet, GPT-5, and Gemini wired in at the editor level. You see your files in a sidebar. You highlight code, hit a shortcut, and tell the model what to change. You can also open a chat panel and have a conversation about your codebase, with the model reading whatever files are relevant. The Pro plan at $20/month covers what most founders need. The free tier exists, but the request limits are tight enough that you’ll quit before you finish the first project.
Why Cursor first, not Claude Code?
I get this question every week from non-engineer founders. The answer is visual safety.
When you’re new to writing code with AI, the scariest moment is realizing the tool just edited 6 files and you have no idea what changed. Cursor shows you every change in a diff view before you accept it. Claude Code can do this too — but the default flow is terminal-first, and terminal-first is uncomfortable for non-engineers. By month two, you’ll have the trust to let Claude Code run loose. Month one, stay in Cursor. The visual layer is the training wheels you actually need.
| Cursor | Claude Code | |
|---|---|---|
| Interface | Visual editor (VS Code fork) | Terminal (CLI) |
| Best for | First 60 days, single-file edits, exploration | Multi-step workflows, automation, agent tasks |
| Cost (entry) | $20/mo Pro | $20/mo Pro or $100/mo Max 5x |
| Diff view | Yes, before every edit | Yes, but terminal-style |
| Learning curve | Low | Medium |
| Non-engineer ready? | Day 1 | Day 30 |
The two tools share the same underlying model in most cases (Claude Sonnet 4.6). The difference is how you interact with it. Start with Cursor. Add Claude Code when the editor starts feeling like a bottleneck.
The 40-minute setup that prevents 90% of pain
Here’s the install plus the rules file. The install is fast. The rules file is the part most non-engineers skip — and the reason they quit by day 10.
Step 1 — Install Cursor (5 minutes)
Download from cursor.com. Pick your operating system. Open the app, sign in with Google or email. On first launch, Cursor asks if you want to import VS Code settings. Click yes if you’ve used VS Code before. Click “skip” if you haven’t — clean slate is better than inherited mess.
Pick your starter language. If you’re a total beginner, pick “JavaScript” — it’s the most forgiving with AI assistance. If you have a specific stack in mind (Python for scripts, TypeScript for web), pick that.
Step 2 — Subscribe to Pro (2 minutes)
Settings → Subscription → Pro, $20/month. Do this before you write a single line. The free tier rate-limits you on the fast models, which is exactly when you don’t want friction. The $240/year cost is below what most founders spend on coffee in 2 months.
Step 3 — Write your .cursorrules file (25 minutes)
This is the part everyone skips. It’s also the difference between a tool that helps and a tool that fights you.
.cursorrules is a plain text file at the root of your project. Cursor reads it on every interaction. It’s where you tell the model your stack, your preferences, your forbidden patterns, and your definition of done. Mine for 500k.io is 180 lines. Here’s a non-engineer starter (copy this, then edit):
# Project rules for [your project name]
## What this is
- A [Astro / Next.js / Python script / Notion API integration] project
- Owned by [your name], a non-engineer founder
- Goal: ship working tools that automate my [content / outreach / sales] workflow
## Stack
- Language: TypeScript (or Python, or whatever)
- Framework: [Astro 5, Next.js 14, etc.]
- Database: [SQLite, Supabase, none]
- Hosting: [Cloudflare Pages, Vercel, Railway]
## Non-negotiable rules
- Never delete a file without asking
- Never run `rm -rf` or any destructive shell command without asking
- Never edit more than 3 files in a single response without listing them first
- Always explain what each change does in plain English in the diff view
- If the task requires installing a new package, list the package and the reason before running npm install
## My preferences
- Prefer simple solutions over clever ones
- Comment every function with what it does in plain English (3 lines max)
- Use camelCase for variables, kebab-case for files
- Error messages should be readable by humans, not stack traces
## Definition of done
- Code runs locally without errors
- I can describe what it does in one sentence
- There's a comment at the top of the file explaining what it's forThat’s the bare minimum. As you discover your preferences, add them. Mine grew from 30 lines to 180 over 4 months — each rule the result of a specific bad output I didn’t want to see again.
Step 4 — Test the shortcuts (5 minutes)
Three shortcuts. Memorize them.
| Shortcut | What it does | When to use |
|---|---|---|
| Cmd+K (Ctrl+K) | Inline edit. Highlight code, press, type instruction, accept or reject the diff | Single-block changes |
| Cmd+L (Ctrl+L) | Chat sidebar. Conversation with the model, references your open files | Questions, exploration |
| Cmd+I (Ctrl+I) | Agent mode (Composer). Multi-file changes, runs commands, ships features | Bigger tasks, full workflows |
The shortcuts get muscle memory in 2-3 days. Ignore every other Cursor feature for the first 30 days. There’s a settings panel with 60+ options. You don’t need any of them.
Day 1-7: what to actually build
The mistake non-engineer founders make in week one: they try to build the SaaS they’ve been daydreaming about. Don’t. Pick something tiny, finish it, ship it, then go bigger.
The five projects I’d hand to a non-engineer founder on day 1:
- A script that pulls your Stripe payments for the last 7 days and posts the total to Slack. ~60 lines. Ships in one Cursor session. Teaches you environment variables and API calls.
- A static landing page for a side project. 1-2 files. Teaches you HTML/CSS/JS basics with AI doing the typing.
- An RSS-to-email digest of your favorite blogs, posted to your inbox daily. ~150 lines. Teaches you cron and templating.
- A Notion-to-Markdown export script for backing up your docs. ~100 lines. Teaches you the Notion API.
- A simple link shortener using a Google Sheet as the database. ~200 lines. Teaches you full-stack basics.
I shipped #1 on my first Cursor day. The Slack message landed at 2:47pm. I spent the next 20 minutes editing the .cursorrules based on what Cursor got wrong. By the time I shipped #3 in week two, the rules file caught 80% of the issues before I had to.
How long should each project take?
If you’re spending more than 3 hours on a project and not shipping, stop. The bottleneck isn’t the model. It’s the scope. Cut it in half. Ship the half. Add features in version 2.
Day 8-21: the 5 lessons I had to learn the hard way
Lesson 1 — Cmd+I is dangerous before you trust the model
Agent mode (Cmd+I) is amazing once you trust it. In week one it’s a trap. It’ll edit 6 files, run 3 commands, and dump a result that looks fine but isn’t. You won’t catch the bug because you didn’t watch the diff carefully on file 4.
Rule I follow: I don’t use Cmd+I until day 14. Until then, every change goes through Cmd+K (single-block, single-diff, accept or reject). It’s slower. It’s also the only way to actually learn what the model gets right and what it gets wrong.
Lesson 2 — Always state the file path in your prompts
Bad: “Add error handling to this function.”
Good: “Add error handling to the fetchStripePayments function in src/lib/stripe.ts. If the API returns a 500, log the error to console and return an empty array.”
The model is better when constrained. State the file. State the function. State the input. State the desired output. Cursor will surprise you with how much it gets right when the prompt is specific.
Lesson 3 — Read every package install
When Cursor wants to install a new npm package, read what it is. Search the name in Google. Check the GitHub repo, the last commit date, the weekly download count. I’ve seen the model suggest deprecated packages, packages with 50 downloads/week, and once a package that had been compromised by a supply-chain attack three months earlier.
Five-second sanity check per package. It’s not optional. According to a 2025 report by Socket on npm supply chain risks, the number of malicious packages on npm grew 31% year-over-year. AI tools don’t filter for trust signals by default.
Lesson 4 — Version control or you’ll cry
Within the first hour of installing Cursor, set up git. Cursor has built-in source control in the left sidebar. Click it, initialize a repo, commit your starter files. Every time you finish a working change, commit it.
I made the mistake of skipping git for my first three Cursor projects. On project two I lost 4 hours of work because I accepted a Cmd+I change that broke everything and I couldn’t undo it cleanly. Git turns “I lost 4 hours” into “I lost 4 minutes (the time since my last commit).”
Lesson 5 — The model will lie to you about what’s done
Cursor’s agent mode will sometimes say “I’ve added error handling and tested the function.” It hasn’t tested anything. It can’t run your tests unless you’ve wired that in.
Rule: don’t trust any claim of “tested” or “verified.” Run the code yourself. Open the terminal, run npm run dev or python script.py, watch it work or fail. The model is great at writing code. It’s worse at confirming that code actually does what it claims.
Day 22-30: when to add Claude Code
By the end of month one, you’ll feel one of two things. Either Cursor is enough, or you’re hitting a wall where you want to chain 5 tasks together without clicking diffs each time. That’s when you add Claude Code.
The pairing I run on 500k.io:
- Cursor for editing, exploring, and any change where I want to see the diff before accepting.
- Claude Code for full workflows — write the article, run the audit, commit, repeat.
- Same project, same files. Both tools read the same repo. They don’t fight.
If you’re at day 30 and Cursor still feels new, don’t add Claude Code yet. Tools should compound on top of competence, not substitute for it. Spend another 30 days with Cursor first. The cost of waiting is $20/mo. The cost of adding Claude Code before you’re ready is hours of cleanup.
For the next step once Cursor feels natural, read Claude Code beginner guide 2026 — same approach, terminal-first.
What about Replit Agent? Codex? Bolt?
Three competitors get mentioned every time I write about non-engineer coding. Quick honest take.
| Tool | Best for | Skip if |
|---|---|---|
| Cursor | Long-term founder workflow, real codebases, daily use | You want one-shot demos, not real tools |
| Replit Agent | Throwaway prototypes, demos, “I want to see if this is possible” | You need to take the project anywhere outside Replit |
| OpenAI Codex (CLI) | Heavy terminal users, scripting workflows | You want a visual editor |
| Bolt.new | Browser-based prototypes, fast UI iteration | You want full local control |
I’ve used all four in the last 60 days. Cursor is the only one I still open daily. The others are either toys (Bolt, Replit Agent) or specific-purpose CLI tools (Codex). For the founder who wants to ship real things and keep shipping them for years, Cursor is the editor.
There’s a fuller comparison in Replit Agent vs Claude Code in 2026 and the best LLM for code 2026 test.
The 30-day non-engineer Cursor checklist
By day 30, all of these should be true. If any aren’t, you have your next task.
| Item | Done |
|---|---|
.cursorrules file exists, 50+ lines, in the project root | Yes |
| Git initialized, at least 10 commits over 30 days | Yes |
| You can use Cmd+K without looking at a cheat sheet | Yes |
| You’ve shipped at least 3 small projects end-to-end | Yes |
| You’ve read every package Cursor suggested before installing | Yes |
| You haven’t accepted a Cmd+I change without reading the diff | Yes |
| You can describe what each of your projects does in one sentence | Yes |
| You’ve added a real human-readable comment to at least one function | Yes |
If you’re at 8 of 8 on day 30, you’ve graduated. Add Claude Code, or just stay in Cursor and keep shipping. Either path works.
What’s the one rule if I only remember one thing?
State the file. State the change. State the test you’ll run to know it’s done.
The non-engineer’s job with Cursor isn’t to write code. It’s to write specifications that are tight enough that the code becomes deterministic. I learned this the hard way over 60 days. You can learn it on day 1.
Cursor doesn’t make you a developer. It makes you a founder who ships code without being one. That’s a different — and in 2026, more valuable — skill.
For more on the broader stack I run, see my live tool stack and the 6-month solo founder real numbers.
FAQ
Do I really need Cursor if I already have Claude Code?
Different jobs. Cursor is the editor — you see your files, you click around, you keep one foot in the code. Claude Code is the terminal agent — you give it tasks and it ships. I run both. Most non-engineer founders I know start with Cursor because the visual layer makes the first month survivable, then add Claude Code in month 2 once they trust the agent enough to let it work without watching.
How much should I expect to spend in month one?
$20 for Cursor Pro. That's it. Skip the free tier — you'll hit the request cap on day 3 and quit. The paid plan gives you fast access to Claude Sonnet 4.6 and GPT-5, plus unlimited slow requests. Most non-engineers don't need anything else for the first 90 days.
Will I break my computer if I let Cursor run commands?
No, unless you tell it to. Cursor asks before running anything destructive. The rule I follow: I never click 'always allow' on shell commands. I read every command before approval for the first 30 days. After that, your gut catches the bad ones.
What's the single biggest mistake non-engineers make with Cursor?
Treating it like ChatGPT. ChatGPT explains things. Cursor edits files. If you ask Cursor a question instead of giving it a task with a file path, you're using a Ferrari to go grocery shopping. State the file, state the change, let it ship.
Do I need to learn the keyboard shortcuts?
Three of them. Cmd+K (inline edit), Cmd+L (chat sidebar), Cmd+I (agent mode). That's the whole keyboard ergonomic for non-engineers. Everything else, you can ignore for the first 90 days.