Explore a New Next.js Project Before Changing It

Before changing a starter project, answer three questions: Which command does this project define for development? Which file should you edit for the page you are viewing? Which setup choices shaped the files in front of you? The answers are more useful than memorizing a starter tree, because they come from the project you actually have.

Record the choices you make

When creating the project, keep a note of the options you select, particularly the router and whether you choose TypeScript. Choose the App Router if that is the path you intend to follow. After creation, compare the directory with those choices rather than assuming that every new Next.js project has identical files.

Do not copy an installation command or a Node.js version requirement from an older tutorial into a new setup. Check the current Next.js installation documentation for both at the point you create the project. Then follow one set of options through the rest of the walkthrough. Switching assumptions halfway through makes it harder to tell whether a missing file is a mistake or simply the result of a different choice.

Read what the project contains

Start at the project root. Open package.json and find its scripts before deciding what to run. Look at the dependencies and the names of the configuration files alongside it. You do not need to understand every setting immediately; first establish which files were generated and which commands the project offers.

Next, inspect the routing directories. If your chosen project contains app/page.tsx, open it and identify the text it displays. Open app/layout.tsx as well and read how it wraps the page. Check public/ for assets referenced by the starter. This turns a directory listing into a map of what you can change: page content, its surrounding layout, and any referenced static files.

Keep router examples separate. If you are following an App Router setup, work from the app/ files in that project. Treat a pages/ example in another tutorial as a different path, not as an additional file to create just to make the examples look alike.

Start the app and trace one edit

Use the development script defined in your generated package.json, with the package manager you used for installation. Watch the terminal for the local address reported by the running process, then open that address in a browser. Using the address the process reports avoids guessing a port that might already be occupied.

Once the page appears, make a small, unmistakable text change in app/page.tsx if that file exists in your project. Save the file and check the browser again. If the visible text does not change, first confirm that you edited the project being served and opened the address printed by its development process. Next, revisit the route you opened and the file you changed. Keep the edit small until that connection is clear.

That single edit gives you a useful starting point for further work: you have identified the project's own run command, found the file you intended to change, and checked its effect in the browser. From there, inspect the layout or assets only when the next change calls for them.