Problem-Solving & Community: Ship Real Work

Part 3 of 3 in the Cursor Mastery series

🧪 Interactive Lab Available: Cursor as a Character Lab →

Master advanced patterns with hands-on challenges.

Explain This to Three People

The Gap Nobody Talks About

You've learned the mindset. You've mastered the workflows.

But here's the uncomfortable truth: None of that matters until you ship something real.

Real = used by someone who isn't you.

Real = code that survives contact with production.

Real = contributions that get merged.

Real = projects that solve actual problems.

The gap between "I can code with AI" and "I shipped real work" is where most people get stuck.

Let me show you how to cross it.

Part 1: Debugging Real Problems

The Scenario

You're staring at a production bug. Users are complaining. The error logs are cryptic. The codebase is unfamiliar. You're on the clock.

This is where Cursor becomes invaluable.

The Pattern: Debug with AI as Your Pair

Step 1: Gather Context (5 minutes)

You: [Open Chat - Cmd+L]

"I have a production bug. Here's what I know:

Error: TypeError: Cannot read property 'data' of undefined
File: @api/users.ts line 47
Stack trace: [paste full trace]
Recent changes: [check git log --oneline -10]

What are the most likely causes?"

What Cursor does:

• Analyzes the stack trace
• Identifies the exact point of failure
• Suggests probable causes ranked by likelihood

Your job:

• Provide full context (error, logs, recent changes)
• Validate Cursor's hypotheses against your domain knowledge

Step 2: Reproduce Locally (10 minutes)

You: "Help me write a test that reproduces this bug:

@api/users.ts - fetchUser function
Error happens when user data is malformed
Expected: graceful handling
Actual: crash with undefined property access"

[Cursor generates test]

You: "Run the test and verify it fails the same way"

Why this works:

• Reproducible bugs are fixable bugs
• Tests document the issue
• You prove the fix works

Step 3: Fix with Inline (5 minutes)

[Select the problematic code]
[Cmd+K - Inline mode]

"Add null check and error handling:
- Check if response.data exists
- Return meaningful error if malformed
- Log the issue for debugging
- Follow error handling pattern from @api/posts.ts"

Review checklist:

• [ ] Handles the specific error?
• [ ] Doesn't break existing functionality?
• [ ] Logs enough for future debugging?
• [ ] Test passes?

Step 4: Verify the Fix (10 minutes)

You: [Chat]

"Review my fix for edge cases:
@api/users.ts lines 45-52

Scenarios to check:
1. User exists, valid data → should work
2. User exists, malformed data → should handle gracefully  
3. User doesn't exist → should return 404
4. Network timeout → should handle error
5. Database connection lost → should handle error

Are there other cases I'm missing?"

Cursor helps you think like a senior engineer:

• Catches edge cases you didn't consider
• Suggests additional tests
• Identifies potential race conditions

Part 2: Contributing to Open Source

The Intimidation Factor

Open source feels scary:

• "What if my PR gets rejected?"
• "What if I don't understand the codebase?"
• "What if maintainers think I'm dumb?"

Here's the truth: Maintainers LOVE good contributions. And with Cursor, you can make good contributions.

The Pattern: First-Time Contributor Flow

Step 1: Find a Good First Issue (20 minutes)

Look for:

• Repos you actually use
• Issues tagged `good-first-issue` or `help-wanted`
• Clear bug reports with reproduction steps
• Active maintainers (recent commit activity)

Red flags:

• Vague issues ("make it better")
• Repos with 100+ open PRs
• No recent maintainer activity
• Critical security issues (not for beginners)

Step 2: Understand the Codebase (30 minutes)

You: [Chat - Cmd+L]

"I want to contribute to this repo: [GitHub URL]
Issue: [link to issue]

Give me a codebase tour:
1. What's the overall architecture?
2. Where is the relevant code for this issue?
3. What's the testing strategy?
4. What are the contribution guidelines?
5. What patterns should I follow?"

Cursor gives you:

• High-level architecture understanding
• File locations for relevant code
• Testing conventions
• Style guide awareness

You do:

• Read CONTRIBUTING.md manually
• Look at recent merged PRs for patterns
• Check CI/CD requirements

Step 3: Make the Fix (1-2 hours)

Use the full toolkit:

[Chat] - Understand the bug deeply
[Composer] - Make changes across multiple files
[Inline] - Refine specific functions
[Chat] - Review your solution before submitting

The review conversation:

You: "Review my fix before I submit the PR:

@components/Button.tsx - my changes
@tests/Button.test.tsx - my test additions

Checklist:
- Does this match the repo's coding style?
- Are my tests comprehensive?
- Did I miss any edge cases?
- Is my commit message clear?
- Anything else maintainers will notice?"

Cursor acts as your pre-submission reviewer.

Step 4: Write a Great PR Description

You: [Chat]

"Help me write a PR description:

Issue: [link]
Changes: [summary]
Testing: [what I tested]

Make it clear, professional, and helpful to reviewers."

Good PR template:

## Summary
Fixes #123 - Button not responding to keyboard events

## Changes
- Added `onKeyDown` handler to Button component
- Implemented Enter/Space key support
- Added keyboard event tests
- Updated accessibility docs

## Testing
- [x] Tested on Chrome/Firefox/Safari
- [x] Keyboard navigation works (Tab + Enter/Space)
- [x] Screen reader announces button correctly
- [x] All existing tests pass
- [x] Added new test coverage

## Screenshots
[Before/After if UI changes]

## Checklist
- [x] Code follows style guidelines
- [x] Self-reviewed the changes
- [x] Commented complex logic
- [x] Updated documentation
- [x] Added tests for new behavior

Step 5: Handle Feedback Gracefully

When maintainers request changes:

You: [Chat]

"Maintainer feedback on my PR:
'Can you use useCallback here to prevent unnecessary re-renders?'

Help me:
1. Understand why this matters
2. Implement the suggestion correctly
3. Explain what I changed in my response"

Cursor helps you:

• Understand the technical reasoning
• Implement requested changes
• Communicate professionally

Your response template:

Thanks for the feedback! You're right about the re-renders.

I've updated the code to use `useCallback` with proper dependencies.
This prevents the onClick handler from being recreated on every render.

Changes: [commit hash]

Let me know if there's anything else!

Part 3: Building Portfolio Projects

The Problem with Tutorials

You've done tutorials. You've built todo apps. Your GitHub is full of half-finished projects.

None of that shows you can ship.

What Actually Impresses

Projects that:

• Solve a real problem (not another todo app)
• Work in production (deployed and live)
• Handle edge cases (error handling, loading states)
• Look professional (good UI/UX)
• Have good code (tests, documentation, clean architecture)

The Pattern: Ship a Real Project

Phase 1: Pick a Problem You Actually Have

Bad ideas:

• "A social network for developers"
• "A better to-do app"
• "Uber for X"

Good ideas:

• "A tool to track my job applications"
• "A dashboard for my crypto portfolio"
• "A bot that notifies me of product restocks"
• "A CLI to automate my deployment workflow"

Why good ideas work:

• You understand the problem intimately
• You're your own first user
• You know what "good enough" looks like
• You'll actually finish it

Phase 2: Build the MVP (1 week)

Week 1 Plan:

Day 1-2: Core Functionality

You: [Composer]

"Build job application tracker MVP:

@app/applications/page.tsx - main list view
@components/ApplicationCard.tsx - individual job card
@app/api/applications - CRUD routes
@lib/db.ts - database setup (use SQLite for simplicity)

Features:
- Add application (company, position, date, status)
- View all applications in a grid
- Update status (Applied → Interview → Offer → Rejected)
- Delete applications
- Sort by date

Keep it SIMPLE. No auth yet. Focus on functionality."

Day 3-4: Polish

You: [Multiple Inline edits]

- Add loading states
- Add error handling
- Add empty states ("No applications yet")
- Add success/error toast notifications
- Improve mobile responsiveness

Day 5: Testing

You: [Chat]

"Generate tests for my application tracker:
@app/api/applications

Cover:
- CRUD operations work
- Validation catches bad input
- Error handling works
- Edge cases (empty data, duplicates, etc.)"

Day 6-7: Deploy

You: [Chat]

"How do I deploy this to Vercel?
- Set up database (Vercel Postgres)
- Environment variables
- Build configuration
- Domain setup"

Phase 3: Document It

README.md template:

# Job Application Tracker

Track your job hunt without the spreadsheet headaches.

## Features
- 📝 Add/edit/delete applications
- 🎯 Track application status
- 📊 Visual dashboard
- 📱 Mobile-friendly

## Tech Stack
- Next.js 14 (App Router)
- TypeScript
- Tailwind CSS
- Vercel Postgres
- Deployed on Vercel

## Live Demo
[your-app.vercel.app]

## Screenshots
[Add 2-3 screenshots showing main features]

## Why I Built This
I was tracking job applications in a messy spreadsheet.
I needed something visual, fast, and easy to update on my phone.

Built with AI assistance using Cursor IDE.

## Running Locally
\`\`\`bash
npm install
npm run dev
\`\`\`

Set up `.env.local`:
\`\`\`
DATABASE_URL=your_postgres_url
\`\`\`

Why this works:

• Clear value proposition
• Shows the live deployed app
• Demonstrates technical choices
• Explains motivation (problem-solving)
• Shows you can deploy and document

Phase 4: Share It

Where to share:

• Twitter/X: "Built a job application tracker to solve my own problem. Tech stack: Next.js + TypeScript + Postgres. Live demo: [link]. Open to feedback!"
• LinkedIn: More professional version, explain the problem-solving process
• Reddit r/webdev: "Built my first production app - job tracker [Show HN]"
• Dev.to: Write a blog post about the building process

What happens:

• People use your thing (validation!)
• You get feedback (learning!)
• Potential employers see you ship (credibility!)
• You start building in public (network!)

Part 4: Building in Public & Community

The Multiplier Effect

Coding alone: You learn and grow.

Coding in public: You learn, grow, AND build a network.

Building in public = shipping + sharing the journey.

What to Share

Good content:

• "Just deployed my first open-source contribution! Here's what I learned about [technical topic]"
• "Debugging production at 2am taught me [specific lesson]. Here's the fix."
• "Built a [tool] to solve [problem]. Live demo: [link]. Would love feedback!"
• "TIL: [specific technical insight with code example]"

Bad content:

• "Just coded for 12 hours straight! #hustle" (no substance)
• "Can't believe this bug exists!" (complaining without context)
• "DM me for collaboration" (vague, low-effort)

Where to Build in Public

Twitter/X:

• Short updates with code snippets
• Screenshots of builds
• Quick wins and lessons
• Tag relevant people/projects

LinkedIn:

• More formal "shipped a feature" posts
• Technical deep-dives as articles
• Career milestones (first PR merged, etc.)

Dev.to / Hashnode:

• Tutorial-style posts
• "How I built X" breakdowns
• Technical explainers
• Series on specific topics

GitHub:

• Keep your repos clean and documented
• Pin your best 3-4 projects
• Write good commit messages
• Keep a streak (but don't stress it)

The Pattern: Share Your Work

After every project/contribution/fix:

• Screenshot it (code, deployed app, merged PR)
• Write 2-3 sentences about what you built and why
• Post on 1-2 platforms (Twitter + LinkedIn or Dev.to)
• Include a demo link if applicable
• Tag relevant communities/people (not spam, genuinely relevant)

Example post:

Just shipped a PR to @ReactRouter fixing keyboard navigation in tabs!

The issue: Tab key wasn't cycling focus correctly when dropdown was open.

The fix: Added proper focus management with useRef + focustrap pattern.

This was my first contribution to a major OSS project. Maintainers were super helpful with code review.

PR: [link]
Issue: [link]

#reactjs #opensource #webdev

What happens:

• Other devs see you shipping real work
• Maintainers/companies notice your contributions
• You start conversations with people in your field
• Opportunities come to you instead of you chasing them

Finding Your Community

Don't try to be everywhere. Pick 1-2 and engage:

Discord/Slack Communities:

• Framework-specific (React, Vue, Next.js)
• Tool-specific (Cursor, VS Code)
• General dev (freeCodeCamp, Coding Den)

How to participate:

• Answer questions when you can
• Share what you're working on
• Ask specific technical questions (not "how do I learn React?")
• Thank people who help you

Reddit:

• r/webdev, r/javascript, r/learnprogramming
• Share projects with [Project] flair
• Engage with feedback constructively

Hackathons/Challenges:

• Dev.to monthly challenges
• Hashnode hackathons
• Local meetups (if available)

Part 5: The Confidence Shift

Here's what happens when you start shipping real work:

Before:

• "I don't know if I'm good enough"
• "Everyone else is better than me"
• "I'm scared to contribute to real projects"
• "My code probably sucks"

After:

• "I've shipped features to production"
• "I've had PRs merged in popular repos"
• "I've built projects people actually use"
• "I can solve real problems"

The confidence doesn't come from tutorials. It comes from shipping.

My First 6 Months Shipping

Month 1: Fixed a typo in a README. Got merged. Felt like a hero.

Month 2: Fixed a small bug in a library I use. Took 3 tries to get the PR right. Got merged. Learned about code review.

Month 3: Built a simple tool for myself. Deployed it. Shared it. 10 people used it. Felt real.

Month 4: Contributed a feature to a medium-sized repo. Maintainer was impressed. Started feeling competent.

Month 5: Built a side project that got 100+ users. Started getting DMs asking how I built it.

Month 6: Got my first freelance client from Twitter. Because they saw I shipped real work.

The pattern: Each success builds on the previous one. Momentum compounds.

Your 30-Day Challenge

Want to go from "I use Cursor" to "I ship real work"?

Week 1: Debug & Learn

• Pick one annoying bug in a project (work or personal)
• Debug it using the pattern from Part 1
• Document what you learned in a tweet/post

Week 2: Contribute

• Find a good-first-issue in a repo you use
• Make the fix using the pattern from Part 2
• Submit a PR (even if it gets rejected, you tried!)

Week 3: Build

• Start a simple portfolio project (pick a real problem)
• Build the MVP using Cursor
• Deploy it somewhere live

Week 4: Share

• Write a README for your project
• Post about it on Twitter/LinkedIn/Dev.to
• Share in 1-2 relevant communities
• Start building in public

By Day 30:

• 1 bug fixed (with documentation)
• 1 PR submitted (or merged!)
• 1 deployed project
• 1 public post about your work

That's more real work than most developers ship in 6 months of tutorials.

The Real Transformation

This trilogy wasn't about learning Cursor.

It was about becoming the developer who ships.

Article 1: Mindset - You learned to think like a pair programmer, not a code generator user.

Article 2: Workflow - You learned to match tools to tasks, automate grunt work, and spend time on what matters.

Article 3: Community - You learned to debug production, contribute to real projects, build things people use, and build in public.

The result? You're not "a developer who uses AI."

You're "a developer who ships real work using the best tools available."

That's the difference between theory and practice.

That's the difference between learning and doing.

That's the difference between aspiring and achieving.

Try This Now

Pick your path:

Path A: The Debugger

Do this: Find one real bug (work or personal project). Debug it using the 4-step pattern.

Time: 30-60 minutes

Goal: Prove you can solve real problems.

Path B: The Contributor

Do this: Find a good-first-issue on GitHub. Try to solve it. Submit a PR.

Time: 2-4 hours

Goal: First real open-source contribution.

Path C: The Builder

Do this: Start a simple portfolio project. Pick a real problem you have. Build the MVP this week.

Time: 1 week

Goal: Deployed project with your name on it.

Path D: The Community Member

Do this: Share one thing you built/learned this week. Twitter, LinkedIn, Dev.to—pick one and post.

Time: 15 minutes

Goal: Start building in public.

The End & The Beginning

You've finished the trilogy.

You know the mindset. You know the workflows. You know how to ship.

Now it's your turn.

Go debug something. Contribute something. Build something. Share something.

The community is waiting for what you'll create.

The Cursor Mastery Trilogy:

• Article 1: Cursor Mindset →
• Article 2: Workflow Mastery →
• Article 3: Problem-Solving & Community (you are here)

Practice everything: Interactive Labs →

Complete the journey: Cursor as a Character Lab →

This is Part 3 (Finale) of the Cursor Mastery series. You've learned the theory. Now go ship something real.

Discussion

What's your first shipped contribution going to be? What's been holding you back? What are you building?

[@JMFG on Twitter](https://twitter.com/jmfg) • Join the discussion →

Bonus: Resources for Shippers

Finding Good First Issues:

• goodfirstissue.dev
• firsttimersonly.com
• GitHub search: `label:"good first issue" language:javascript`

Building in Public:

• @swyx - Learn in Public manifesto
• @Dayhaysoos - Build in public veteran
• buildinpublic.com - Community & resources

Communities:

• Cursor Discord
• Dev.to
• Hashnode
• r/webdev

Deployment Platforms:

• Vercel - Next.js apps
• Netlify - Static sites
• Railway - Full-stack apps
• Render - Databases + apps

Keep shipping. 🚀