This is the second part of a series about launching and building real products with the help of AI.

Who is this series for?

If you’ve already gone through the previous part, you should now have a few concrete things in your hands:

In this part, we’ll prepare the environment and actually kick off development.

What needs to be done?

Cursor does not create some special hidden project format. It simply opens a normal folder on your computer. So first we create the project folder and turn it into a Git repository, and only then do we open that same folder in Cursor.

What is Git, and why do you need it?

Git is a version control system. Put simply, Git turns a normal folder on your computer into a repository where all file changes can be tracked. You create restore points yourself by saving snapshots of the files in that folder. Those snapshots are called commits.

When you write code manually, you usually change things gradually and more or less understand exactly what you did. But AI can rewrite many files at once, and not always in a good way. That is why, when working with AI, Git is not an optional extra. It is something you should use from day one.

Git also lets you keep the full history of your project in the cloud for free. Uploading a commit to the cloud is called a push.

Step 1. Create a GitHub account

First, go to GitHub and sign up.

You need this so your project has a remote copy online. That is where your saved versions will be sent later, in other words, where your commits will be pushed.

Store your login details somewhere safe. In development, your GitHub account is a bit like your Google account in everyday life. You will keep using it constantly.

Step 2. Install Git

Now install Git.

Yes, GitHub Desktop, which we will install next, already includes its own built-in Git for basic work. But having Git installed separately is still useful, because it gives the AI proper access to Git and makes commits work more reliably.

During installation, keep the option that makes Git available from the command line and third-party software. This matters because tools like Cursor rely on the system Git, while GitHub Desktop’s built-in Git is not meant to replace that setup.

Step 3. Create your project folder

Before installing the other tools, create a proper folder for the project. We will turn that folder into its repository.

On Windows, it is better to use a short path right away, for example:

C:\Projects\my-project or C:\Users\me\my-project

Do not keep your working project folder inside a OneDrive-synced location. For example, my Desktop is synced, so it is not a great place for a repository folder.

Step 4. Install GitHub Desktop

Now download and install GitHub Desktop.

This is the app that lets you work with Git through normal windows and buttons instead of the command line.

After installation, sign in with the GitHub account you created in Step 1.

Step 5. Create a local repository

Now you already have a project folder. The next step is to turn it into a Git repository.

Open GitHub Desktop. In the menu, choose:

File → New repository

In the Name field, enter your project name. It is best if it matches the folder name.

In the Local path field, choose the folder you created earlier, for example:

C:\Projects\my-first-project

Then click Create Repository.

Step 6. Publish the repository to GitHub

Once the local repository is created, GitHub Desktop will usually suggest the next step: Publish repository.

Click that button.

A window will open where you can check the repository name and optionally add a description. After you confirm, the project will appear on your GitHub account as well.

Step 7. Install Cursor

What is Cursor?

Before we install Cursor, let’s quickly clarify what it is.

Cursor is an IDE (Integrated Development Environment). This is not just a text editor where you write code. An IDE is a full development environment that works with your entire project.

It treats a folder as a structured set of connected files, indexes them, and provides tools to work with the project as a whole. This includes things like navigation, search, and a built-in terminal (shown as element 7 in the screenshot).

Cursor is built on top of VS Code, a widely used and well-established IDE.

On top of that, Cursor adds a key layer: an integrated AI interface (highlighted in yellow in the screenshot). This allows you to interact with an LLM directly inside your project.

Instead of just editing files manually, you can:

In other words, Cursor turns your IDE into an environment where AI actively participates in development.

Installation & Setup

Install Cursor, then sign in to your Cursor account and subscribe to the $20 plan.

Step 8. Open your project folder in Cursor

Open in Cursor the exact same folder that you already prepared and turned into a Git repository.

File → Open Folder

This is the folder where your code, README.md, Cursor settings, and the full Git history will live.

Step 9. Enable the models you need

Go to:

Cursor Settings(4) → Models

At this stage, three models are enough:

Step 10. Connect the documentation

Cursor can use documentation so the agent relies not only on your prompt, but also on official references.

Go to:

Cursor Settings(4) → Indexing & Docs → Add Doc

Then add:

Step 11. Create README.md

Now, prepare the file that will explain the project both to you and to the AI.

In the root of the project, meaning inside the folder you created, create a file called: README.md

Take the technical specification text from Part 1 and copy it into this README.md.

One important note here: this text does not have to be identical to your first prompt for Cursor. As I suggested in Part 1, you can start development with a small and very focused piece of the product. But the full description should still live in README.md, so the AI understands what the overall destination is.

Step 12. Create rules for Cursor

Cursor allows you to define rules that the AI will read before answering any question or executing any task. These rules act as a persistent context layer and help keep the system stable.

There are two types of rules:

For now, we’ll create a couple of simple but critical user rules.

Go to:

Cursor Settings → Rules, Skills, Subagents → Rules → New → User Rule

Create this rule first:

Always read README.md before making changes

Save it, then create a second one:

Never drop or delete tables in the remote database

And the third:

Whenever a database change is needed, always create a new Supabase migration file and save it in the migrations folder

You can find many ready-made rule sets online, but in practice, a small number of well-defined rules often works better than a large generic list.

In my case, these rules worked reliably in my second project, especially combined with the fact that some constraints were also embedded directly into the technical specification inside README.md.

Supabase provides CLI tools and more advanced ways to sync your database with your local project. In theory, this is a more “correct” approach. In practice, it often introduces additional complexity, edge cases, and wasted time. That’s why I use the simplest and most reliable approach — managing changes through migration files only. I’ll explain this in more detail later.

Step 13. Make your first commit

Go back to GitHub Desktop.

Most likely, you will now see new files there:
README.md, possibly .cursor/..., and maybe a few others.

At the bottom of the GitHub Desktop window, there will be a field for the commit message. Enter something like:

Initial project setup

Then click Commit to main, and after that Push origin.

This is your first saved checkpoint. From this moment on, your project already has an initial version you can return to at any time.

Step 14. Create a Supabase account

Now create a Supabase account and your first Supabase project.

1. Create a Supabase account

2. Create an organization

Technically, Supabase does have a Free plan, and it includes up to two free projects. But in practice, if you plan to use Google login properly, you may quickly run into the need for a paid setup.

3. Create your first project

4. Get your API keys and URL

5. Enable authentication (optional but common)

At first glance, Supabase may look like something you can leave for later, but in this stack it is your backend from the very beginning. This is where your database, authentication, storage, and other backend features will live.

At this stage, you do not need to connect Supabase to Cursor directly.

A safer workflow is this:

Step 15. Start the first development task in Cursor

Now open Cursor and go to the chat panel, the one I marked with a yellow label in the screenshot.

Before sending anything, make sure to switch selector 5 to Opus 4.6 or any newer available version, and switch selector 6 to Agent mode.

Then paste into the chat the prompt you prepared in Part 1. This is not the full technical specification from README.md, but here you should paste the actual starting prompt for the first development task.

You can attach your full technical specification to the message with your first prompt. In principle, if you’ve defined a rule to always read the README, Opus should pick it up and process it on its own.

For your first prompt, definitely use Opus. Don’t rely on the free tier here, it’s better to get the project moving in the right direction from the start.

Press Enter. Enjoy.

Important note about .env.local

At some point, usually right after Cursor generates the initial Supabase integration, you will most likely be asked to create a .env.local file in the root of the project.

This file is used for environment variables, such as your Supabase project URL and public API key.

You do not have to create this file blindly in advance if your code does not need it yet. A simpler approach is to wait until Opus generates the first Supabase-related code and tells you exactly which variables are required.

For security reasons, the LLM will not create the .env.local file with real values on its own. Instead, it usually generates a .env.local.example file that shows which variables are expected.

When that happens, create .env.local, paste in the requested values, and save the file.

Next.js

Also note that Cursor will typically suggest installing Next.js automatically when it generates the initial project structure. You usually only need to confirm the installation when Cursor asks for permission to run the required command.

Step 16. Run your app

Open the terminal in Cursor (marked #7 in the screenshot above) and make sure you are in the project folder you selected in Step 3.

In the terminal, the current folder is shown at the beginning of the line. For example:

C:\Projects\my-project>

If the current folder is different from the project folder you selected in Step 3, you need to navigate to it.

You can move through folders using simple commands (place the cursor after the > symbol in the terminal line, type the command, and press Enter):

cd ..
Movesone level up in the folder hierarchy.

cd [folder-name]
Movesdown the folder hierarchy from the current folder into the folder you specify.

For example: cd my-project

Use these commands until the terminal line shows the path to your project folder.

Once you are in the correct directory, type:

npm run dev

After you type the command, the full line in the terminal should look something like this:

C:\Projects\my-project> npm run dev

Press “Enter”.

After that, open http://localhost:3000 in your browser and look at the result (Cursor may also open it automatically in its built-in browser preview).

If something does not work the way you expected, go back to Opus and describe the problem clearly. If the application does not start, copy the error message from the terminal and paste it into the chat so Opus can see exactly what went wrong.

Keep in mind that copying text from the terminal may work differently from regular applications, depending on your operating system.

Windows (Command Prompt / PowerShell / Cursor terminal):

macOS:

Linux:

In most terminals, you don’t need to type the same command again if you already ran it before. You can use the Up and Down arrow keys on your keyboard to scroll through previously entered commands.

In practice, most problems when running npm run dev happen for two simple reasons:

Don’t worry about diagnosing this yourself. Opus will usually recognize the problem immediately from the error message and suggest the correct solution. Just copy the error text from the terminal and paste it into the chat.

You can copy into the chat not only error messages, but also screenshots showing errors or incorrect behavior of your application.

Here is an example of the isometric map editor I got after applying my first prompt (I included the full prompt text in Part 1). It already felt quite tangible: I could immediately start drawing paths and editing the map. The first bug I noticed was an issue with mouse wheel zoom, but otherwise everything was working.

Over time, I fixed this bug and improved the controls and visuals. The result looks like what you see below.

You can evaluate the level of engine development using the Bach family park as an example at the following link.

Now let’s move on to how to evolve your first version

Step 17. Commit your changes

Once everything looks okay, open GitHub Desktop.

In the left panel, you will see a list of files that were created or changed during the previous steps.

At the bottom of the window, enter a short commit message in the Summaryfield.
This is the title of your commit and should briefly describe what changed.

For example:

First version

Then click Commit (n) files to main.

This saves the changes in your local Git history.

After that, click Push origin at the top of the GitHub Desktop window.

This uploads your changes to your repository on GitHub so they are safely stored online. Once the push is complete, your project files will appear in your GitHub repository.

If you have never worked with development tools before, I understand that all of this may look strange and complicated at first. But don’t worry about it too much. As someone who also did not write code before, I got used to this process surprisingly quickly. Within a week or two it started to feel completely normal.

After a while, running commands in the terminal feels no more unusual than opening Word or any other application on your computer.

Step 18. Prepare the first version for deployment

Up to this point, running your product locally at http://localhost:3000 was enough. In this setup, your own computer effectively acts as the server.

But sooner or later, you need to put your service online and make it accessible to other users. Uploading your product to a server is called deployment.

You don’t need to deploy every small change unless you specifically want others to test it. In my experience, I deploy roughly every 10th change. The reason is simple — deployment takes a few minutes, and waiting every time slows you down.

For most iterations, it’s enough to run the project locally using:

npm run dev

But now let’s reach a first logical milestone, finalize a working version, and prepare it for deployment.

Enter your next task in the chat

Review the current implementation. What is missing and what works incorrectly? Simply ask model to fix issues or add a feature.

Then move step by step, giving the system clear tasks with one specific expected outcome that you can immediately verify.

After each change, check the result locally with:

npm run dev

For example, here’s what I wrote to Cursor after my first version started working:

It’s not very clear how to navigate the map. Sometimes it drifts toward the top of the screen. It would be great to distinguish between a click and a drag (for moving around the map), and a click for placing the selected element.

And then:

Great, now make it zoom with the mouse wheel.

And then:

Great! How do I integrate images now? What format should they be in: PNG, SVG, or something else?

And then:

I didn’t quite understand what the tile file should look like. Could you create an example tile file for grass (I’ll draw any grass myself), place it where it should go, and connect it to the project? I’ll make the rest following that example.

Then I noticed that the paths were rendering incorrectly and added this screenshot to the chat, explaining: the paths look completely wrong — they seem rotated by 45 degrees and don’t form continuous lines.

Opus fixed it on the first try:

Use separate chats for separate tasks

Always start a new chat for a new block of tasks.

My rule is simple: if the new task is not directly related to the previous one — open a new chat.

LLMs reload the entire conversation every time, so splitting tasks into separate chats helps:

Define tasks at the architecture level

Avoid vague requests like:

Add comments under articles

Instead, define structure and constraints:

Create a comments component in a separate file. It should be displayed under the article block. The article owner can hide comments. The comment author can edit their comment. Comments must be stored in a separate database table. Each comment should include: text, author, moderation status, created_at, updated_at. Maximum length: 1500 characters.

Then, in a separate prompt:

Add reactions to comments. Each user can leave only one reaction. Authors cannot react to their own comments. Store reactions in a separate table. Start with 3 types: like, fire, 100%. For now, hardcode reaction types (we may move them to a table later).

Review generated files before accepting

Before clicking “Accept all”, always review the generated code.

Make sure files don’t grow too large:

You can also control where components are created:

Create a comments component in a new file

Choose the right model

From my experience:

Model is selected via selector (5 in the screenshot).

For simple UI changes or questions (Ask mode, selector 6), I often switch to Auto to reduce costs.

Commit after every successful task

Do this consistently. Keep GitHub Desktop open and commit after every successful step.

In the left panel of GitHub Desktop, you will see a list of files that were created or changed during the current task.

At the bottom of the window, enter a short commit message in the Summaryfield.
This is the title of your commit and should briefly describe what changed.

For example:

Added: comment reactions

Then click Commit (n) files to main.

This saves the changes in your local Git history.

After that, click Push origin at the top of the GitHub Desktop window.

Keep your README updated

After finishing and testing a feature, ask Cursor to update your README.md.

Add a short summary of:

Manage database changes through migrations

There are more advanced ways to sync your database (CLI, etc.), but in practice they often introduce instability and waste time. I recommend a simpler and more reliable approach: use migrations only.

  1. When you need to update the database ask Cursor to create a migration file (if your spec is well-defined like we did in Part 1, it will often do this automatically).

  2. Migration files will appear in YOUR_PROJECT/supabase/migrations like 0001_initial.sql, 0002_add_comments.sql, etc.

  3. When a migration file is ready copy its contents, paste into Supabase SQL editor (1) and click Run (3):

  4. Make sure Cursor does not modify migration files that you have already applied. To do this, explicitly tell it in your next message whether the migration has already been applied or not. If it has been applied, it must create a new migration file. If not — it can update the current one.

If you notice that it started editing an already applied migration, tell it to revert the changes and create a new file instead.

MCP-Servers

You may have already come across MCP.

It’s a very elegant idea and a universal protocol that allows you to give your LLM inside Cursor additional “hands” and extend its capabilities. There are MCP servers that allow the LLM to control a browser, interact with other programs, improve code quality, and more.

Personally, I used MCP Supabase, Browser Navigate, Context7 at the beginning, but later stopped. The reasons are simple: instability, additional load on the machine, and loss of control over the development process.

Try them if you want, but in my experience, you can build real software without them.

Step 19. Deploy your first version

Register and connect your domain

After you register a domain with any provider (for example, GoDaddy), you need to:

To make your app URL look clean, use a custom domain in Supabase (costs $10/month).

If you’re not sure how to do this, ask ChatGPT or Cursor what exactly needs to be done.

Deploy the project to Fly.io

In the terminal (7), run:

flyctl deploy --remote-only

or:

flyctl deploy --remote-only --strategy immediate -a YOUR_PROJECT

Here, YOUR_PROJECT is the name of your app in Fly.io — the one you specified when creating the project.

Wrapping Up

I’d like to wrap up the second part by saying that, overall, the information covered in Parts 1 and 2 should be enough for you to dive in and continue developing your product on your own.

I might later put together another piece, either a separate part with practical tips and lessons I’ve learned, or a standalone article with real-world cases.

In any case, good luck with building your project!