How I Use Cursor to Build App Features With AI

Building an app without a traditional coding background sounds difficult. And to be honest, it still comes with plenty of challenges.

But AI development tools have changed how I approach software development.

I'm a former B2B software sales professional building my own consumer apps. One of my current projects is HomeGoal, an app designed to help people make progress toward buying a home. I'm building it with the help of AI tools, using technologies such as Next.js, TypeScript, and Supabase.

My main development tool is Cursor.

Instead of writing every line of code myself, I use AI to help me understand my codebase, implement features, investigate bugs, and improve the application step by step.

That doesn't mean I can simply describe an entire app and expect everything to work perfectly. I still need to make product decisions, understand what the AI is changing, test the results, and fix problems along the way.

In this article, I'll explain how I approach building features with Cursor, how I structure my instructions, and what I've learned about using AI effectively when you're still learning software development.

What is Cursor, and why do I use it?

Cursor is an AI-powered code editor designed to help developers work with code using AI. Its features can help you understand a project, make changes across files, fix bugs, and review generated code.

What makes it useful for me is that I don't need to understand every technical detail before asking for help.

I can describe a feature in plain English, ask questions about unfamiliar code, and use AI to work through implementation problems.

For example, imagine I want to improve a savings progress feature in HomeGoal. I can start by explaining what the user should be able to do, ask Cursor to investigate how the existing feature works, and then work through the changes needed to implement the improvement.

Cursor can help with the technical work, but I remain responsible for deciding what the feature should do and checking whether the result meets that goal.

You can explore the tool on the official Cursor website.

My development setup

Before looking at my workflow, here's the basic setup I use to build my apps.

• Cursor: My main environment for AI-assisted coding.
• Next.js: The application framework I use for building the web app.
• TypeScript: The programming language I use to build the application.
• Supabase: The backend platform I use for services such as the database and authentication.
• GitHub: Where I manage and store the application's source code.

Each tool has a different role. Cursor helps me work with the code, Next.js and TypeScript form part of the application itself, Supabase provides backend functionality, and GitHub helps me manage changes to the project.

You don't need to use exactly the same stack to follow this workflow. The underlying principles apply to many AI-assisted development setups.

Step 1: Start with the problem, not the code

When I want to build a new feature, my first step is to clarify what I'm trying to achieve.

This sounds obvious, but it's easy to jump straight into asking AI to implement something before you've thought through the actual user experience.

Suppose I want to improve how users track their savings progress.

Before touching the code, I should answer a few questions:

• What problem is the user experiencing?
• What should the user be able to do after the change?
• What information does the feature need?
• How should it behave in different situations?
• How will I know whether the implementation works?

These questions help me separate the actual product requirement from the technical solution.

For HomeGoal, the goal is to help people understand their progress toward a home-buying savings target. A feature should support that goal rather than add complexity for its own sake.

Once I understand the intended outcome, I can explain it to Cursor.

Step 2: Ask Cursor to understand the existing code first

One of the mistakes you can make when using AI to build an existing application is asking it to change something before it understands how the application currently works.

Even a seemingly small feature can depend on several parts of a project: the user interface, data structures, calculations, authentication, and backend logic.

If you ask for a change without enough context, AI may make assumptions that don't fit your existing architecture.

I prefer to begin by asking Cursor to investigate the relevant parts of the codebase and explain how they work.

For example, I might use a prompt like this:

Example Cursor prompt

I want to improve the savings progress feature in my application.

Before making any changes, inspect the existing implementation and explain how it currently works.

Identify the relevant components, data structures, calculations, and backend interactions. Explain how these parts connect and point out anything I should understand before implementing the change.

Do not modify any files yet. If anything is unclear, tell me what information is missing.

The important part is the instruction not to make changes yet.

I want to understand the current implementation before deciding what to change. This also gives me an opportunity to ask follow-up questions when Cursor identifies something I don't understand.

My takeaway: Use AI to understand your application, not just to generate more code.

Step 3: Break the feature into manageable tasks

Once I understand the existing implementation, I can work out how to approach the change.

Rather than asking Cursor to implement an entire feature in one large instruction, I try to break the work into smaller, understandable tasks.

Depending on the feature, that might mean:

1. Updating the underlying calculation or business logic.
2. Adjusting the relevant user interface.
3. Connecting the interface to the required data.
4. Handling loading states, missing information, and errors.
5. Testing the complete user flow.

Not every feature needs all five steps, and some changes require a different sequence. The point is to make the work easier to reason about.

For more complex changes, I ask Cursor to propose an implementation plan before proceeding.

For smaller changes, a concise explanation of the proposed approach may be enough.

This helps me identify potential problems earlier. If the proposed solution doesn't make sense, I can ask questions or adjust the plan before the AI modifies several files.

It also makes debugging easier because I can narrow down which part of the implementation introduced a problem.

Step 4: Give Cursor specific instructions

The quality of an AI-generated result depends partly on the instructions you provide.

Compare these two requests:

Too vague:

Improve the savings dashboard.

More specific:

Review the existing savings dashboard and identify the component responsible for displaying progress toward the user's savings target.

I want the dashboard to communicate three things clearly: the target amount, the amount already saved, and the remaining amount.

Reuse the existing design patterns and data structures wherever possible. Before changing the code, explain which files need to change and how you will calculate the remaining amount. Do not change unrelated parts of the application.

The second prompt gives Cursor more context about the desired outcome, the constraints, and the expected process.

I also try to specify what should not change. This matters because a small feature request shouldn't unexpectedly alter unrelated parts of the application.

You don't need to write an enormous prompt every time. For simple tasks, a few clear sentences may be enough. For complex tasks, more context and explicit requirements can save time later.

A useful structure is:

• Goal: What should the feature accomplish?
• Context: How does the relevant part of the application work today?
• Requirements: What behavior should be implemented?
• Constraints: What should remain unchanged?
• Verification: How should the result be tested?

This structure helps me turn a vague idea into an actionable development task.

Step 5: Review the changes instead of blindly accepting them

Once Cursor has implemented a change, the work isn't necessarily finished.

AI can produce code that looks reasonable but contains bugs, misunderstands the intended behavior, or introduces unintended side effects.

That's why I pay attention to the changes themselves.

Cursor provides a way to review code differences, so I can inspect which files were modified and what was added, changed, or removed.

When reviewing a change, I want to understand:

• Which parts of the application were affected?
• Does the implementation match the original requirement?
• Were unrelated files changed?
• Are there potential problems with data handling or existing functionality?
• What should I test before considering the feature complete?

Because I'm not an experienced developer, I also use AI to explain unfamiliar changes.

For example, I can ask:

Explain the changes you just made in plain English, file by file. Tell me how the changes implement the requested feature, what assumptions you made, and what could go wrong. Highlight anything that needs particular attention before I test it.

This doesn't guarantee that the code is correct. AI can miss its own mistakes, so explanations must be combined with testing and, where appropriate, additional review.

But it helps me build a better understanding of my own application rather than treating the codebase as a black box.

Step 6: Test the feature in the actual application

A feature isn't complete just because Cursor has finished generating code.

I need to check whether it behaves as expected in the application itself.

For a savings progress feature, that might include testing a normal savings amount, a zero balance, an amount equal to the target, and an amount that exceeds the target if the application allows it.

I would also check what happens when information is missing or when something goes wrong.

The specific tests depend on the feature, but I try to think beyond the ideal scenario.

A useful prompt is:

Review the feature requirements and implementation. Identify the most important test cases, including edge cases and possible failure scenarios. Explain how I can verify each one and which tests can be run automatically.

I then work through the relevant checks. Depending on the changes, that can include running automated tests, checking application output, reviewing error messages, and manually trying the user flow.

If something doesn't work, I use the actual error or unexpected behavior as context for the next investigation.

This is much more useful than repeatedly asking Cursor to fix something without explaining what went wrong.

The key lesson is simple: test the behavior, not just the code generation.

Step 7: Use errors as information

Debugging is one of the areas where AI can be particularly helpful when you're learning to build software.

An error message that would previously have sent me searching through unfamiliar technical documentation can now be a starting point for a conversation with Cursor.

But I try not to jump straight to a solution.

First, I want to understand what the error means, where it originates, and what evidence is available.

A useful prompt might be:

I'm experiencing the following problem:

[Describe the issue or paste the relevant error message.]

First, investigate the likely cause using the available code and error information. Explain your reasoning in plain English and identify the smallest appropriate fix.

Avoid changing unrelated functionality. After implementing the fix, explain what changed and how I can verify that the issue is resolved.

This gives Cursor a clear task while encouraging a more systematic approach.

Sometimes the first explanation is wrong. Sometimes the error is only a symptom of a different problem. And sometimes fixing one issue reveals another.

That's part of building software.

The goal isn't to avoid every error. It's to develop a process for investigating problems without making the application harder to maintain.

Step 8: Protect the project before making bigger changes

AI can make changes quickly, but speed is not particularly helpful if you lose track of what changed or can't recover from a bad implementation.

That's why version control matters.

I use GitHub to manage my application's source code. Git makes it possible to track changes over time, compare versions, and return to earlier states when necessary.

Before larger changes, I want to know that my current work is safely recorded and that I can recover if the implementation goes wrong.

Cursor also offers checkpoints for restoring certain AI-generated changes, but these are not a replacement for Git or a proper version-control workflow.

This becomes increasingly important as an application grows. A small experiment is one thing; changing authentication, database logic, or several interconnected features requires more care.

My general principle is to make changes in manageable steps, inspect the result, and keep a reliable history of the project.

What I've learned about building with Cursor

Working with AI development tools has changed how I think about building software.

Here are the principles I keep coming back to:

1. Clear requirements matter more than clever prompts. You need to understand what you're trying to build before asking AI to implement it.
2. Context prevents unnecessary mistakes. Help Cursor understand the existing application before requesting changes.
3. Smaller tasks are easier to control. Break complex features into manageable steps and review the result along the way.
4. Understanding is still important. You don't need to know every line of code, but you should understand the purpose and risks of important changes.
5. Testing is part of development. Never assume a feature works simply because the AI says it is finished.
6. A good workflow matters as much as the tool. Version control, clear requirements, careful reviews, and systematic debugging help keep development manageable.

Cursor can make the technical side of building an app more accessible, particularly if you're starting without a traditional coding background. But it doesn't eliminate the need for sound product decisions or responsible development practices.

The real opportunity is being able to combine AI's capabilities with your own knowledge of customers, problems, and business.

Final thoughts: Build products, not just code

My goal isn't to become an expert at writing prompts for Cursor.

My goal is to build useful apps, understand the products I'm creating, and turn them into sustainable businesses.

That means spending time on development, but also on product decisions, customer feedback, positioning, and marketing.

For HomeGoal, the technology is a means to an end: helping people make progress toward a major financial goal. The same principle will guide the other apps I build in the future.

If you're starting from zero, you don't need to understand everything before you begin. Start with a manageable problem, use AI to help you learn, work in small steps, and verify the results.

You will make mistakes. You'll encounter unfamiliar concepts. Some solutions will work, and others won't.

What matters is building a process that helps you learn from each iteration.

I'm documenting my journey as I build apps with AI, including the tools I use, the decisions I make, and the lessons I learn along the way.

If you're interested in following that journey, explore more articles on andihein.com and follow along as I continue building and marketing my apps.

Next up: I'll share more about turning an app idea into a manageable MVP and the product decisions that help me decide what to build next.