How to Build a Prototype with Cursor

What do you need before you open Cursor?

Cursor assumes a working codebase, not a blank page. Before you write a single prompt, you need three things in place: a project already scaffolded (a git repository with a real folder structure, even a minimal one), a specific feature or screen you want to prototype, not a vague product idea, and enough familiarity with your stack that you can read a diff and tell whether it makes sense. Builders Camp's Building with Cursor bootcamp states this directly: the programme is designed for developers with real-world experience who want to integrate AI into a daily workflow, and it expects you to be comfortable writing code in at least one language.

A free Cursor account is enough to start. The Pro plan adds a larger monthly usage pool and unlimited tab completions across models, which matters once you move from a single prototype session to daily use, but it is not a prerequisite for building your first one.

How do you actually build a prototype in Cursor, step by step?

The workflow that keeps a prototype from turning into a pile of half-finished edits has three stages, and Cursor gives each one its own mode.

1. Scope the feature in one or two sentences. Before opening Cursor, write down exactly what the prototype needs to do. "A form that lets a user submit feedback and see it in a list" is scoped. "A feedback system" is not.
2. Explore with Ask mode. Open the chat, switch to Ask, and use @mentions to point Cursor at the relevant files. Ask it to explain how the closest existing feature works before you touch anything. Ask mode searches the codebase and answers without editing a single file, which is exactly what you want before you commit to an approach.
3. Write the plan in Plan mode. Switch modes (Shift+Tab rotates through them, or type /plan) and describe the feature. Cursor researches the code, asks clarifying questions, and generates a plan you can read before any code changes. Read it like you would read a colleague's pull request description: does the list of files match what you expected? Is anything missing?
4. Execute with Agent mode and review the diff. Once you approve the plan, Agent mode edits files, runs terminal commands, and fixes errors it hits along the way. Do not accept the diff on sight. Read every changed file and ask yourself whether it matches the plan you approved.
5. Test the feature by hand. Run the app, click through the flow you scoped in step one, and confirm it behaves the way you described it. If something is off, go back to Ask mode and ask why, rather than immediately re-prompting Agent mode to "fix it."
6. Capture a reusable pattern. If the prompt sequence worked well, turn it into a Cursor rule or a saved prompt. The next prototype starts faster because you are not re-deriving the same instructions from scratch.

What should a PM do differently from a developer using Cursor?

A developer already knows what "done" looks like at the code level: tests pass, the diff is small, the function does one thing. A PM using Cursor for the first time usually does not have that instinct yet, so the discipline has to come from somewhere else: the scope you write down in step one.

Write the acceptance criteria before you open the chat, not after you see what Cursor built. "The form saves to the database and shows a confirmation message" is something you can check against the running app without reading a line of code. Lean on Ask mode more than a developer would; asking "explain this to me" costs nothing and closes the gap between what the diff says and what you actually understand. And treat Plan mode as non-optional. A developer might skip straight to Agent mode on a change they can predict; a PM should not, because the plan is the one artifact you can evaluate without reading code line by line.

Where do most people get stuck building a prototype in Cursor?

Three patterns account for most stalled prototypes, and they compound if you do not catch them early:

• Skipping Plan mode on anything beyond a one-line fix, which means the first time you see the scope of a change is in the diff, after it is already written.
• Accepting a diff because the one feature you were watching for works, without reading the rest of the file for changes you did not ask for.
• Treating every error as a reason to re-prompt from scratch instead of asking Cursor, in Ask mode, why the error happened.

That third one is the expensive one. A prototype that keeps getting re-generated from a fresh prompt every time something breaks never accumulates the small fixes that would have made it stable. Use version control deliberately: commit working states often, so a bad Agent-mode run is a git diff away from being reverted, not a reason to start over.

When should you stop using Cursor and move to something else?

Cursor is a strong choice while the prototype lives inside a codebase you or an engineer will eventually own directly. The honest limit shows up the moment the prototype needs to move faster than you can read code, or the moment nobody on the team can evaluate a diff at all. If your team is entirely non-technical, a tool built to hide the code, like Lovable, will get a demo in front of a stakeholder faster, because it does not require anyone to review terminal output or file structure along the way. If the eventual goal is a full production system with agents, automation pipelines, and multi-file orchestration rather than a single prototype, that is a different scope than Cursor's per-feature workflow is built for.

Cursor compared with the other prototyping paths

Tool	Best for	Requires reading code	Limits
Cursor	Developers extending a real codebase with AI assistance	Yes	Free tier caps agent usage; Pro adds a larger monthly pool
Lovable	Non-technical builders who want a full-stack app with no code shown	No	Prototype only; production concerns like auth and billing are a separate step
Replit	Builders who want to code and deploy from the browser, including mobile-friendly Agent use	Some	Effort-based Agent pricing means cost scales with request complexity

Who this is for, and who it is not for

Cursor is for software developers, full-stack engineers, and product-minded builders who already write code and want AI to speed up the parts of the workflow that are still slow: exploring an unfamiliar area, drafting a plan, writing the first pass of an implementation. It is also a fit for tech leads setting AI development standards for a team, per Builders Camp's own audience description for the Building with Cursor bootcamp.

It is not the right first tool for someone who has never opened a terminal and does not plan to. Builders Camp's platform-wide FAQ states that no technical or coding skills are needed to use the Membership generally, but that claim does not extend to Building with Cursor specifically, whose stated audience is developers. If that describes you, start with a tool designed around hiding the code rather than showing it.

Build the workflow with a structured cohort instead of trial and error

Reading about the Ask, Plan, Agent loop and actually running it under a working developer's eye are different experiences. Builders Camp's Building with Cursor bootcamp runs the whole workflow in 1 week across 2 live sessions, taught by Tiago Pedro da Costa, Co-founder and CTO of Zumer, and includes a practical challenge where you ship a real feature through the full loop and walk away with a reusable rule.

See the Building with Cursor bootcamp

If Cursor's code-first workflow feels like the wrong entry point, Building an MVP with Replit and building a prototype with Windsurf cover two AI coding tools with a gentler ramp, and how to build a prototype with Lovable covers the no-code path for builders who do not want to see code at all. Once your prototype needs to talk to outside tools and services, building an AI assistant with MCP picks up exactly where a Cursor-built prototype leaves off.