Create a React application by choosing a framework or a deliberately limited learning setup, then build one complete user journey. A working development screen is the starting point. Before production, decide how routes, data, errors, rendering and deployment will work, and record the checks that show the chosen setup meets those needs.
For a first project, keep the user task small enough to finish. A searchable list with a detail view is more useful than several unfinished features. It exposes the decisions that a blank starter screen hides: a direct link, missing data, a failed request and an empty result.
This guide separates the choice of starter from the acceptance of the resulting application. Its original route-and-state card gives a beginner and a reviewer something specific to discuss. It also prevents a successful local build from being treated as evidence that authentication, operations or deployment have already been solved.
Should you start with a framework or a build tool?
React recommends starting a new app or website with a framework. The official starting guide presents frameworks as the normal route, while recognising learning projects and constraints that justify starting from scratch. Write down which situation applies before following a starter command.
The recommended full-stack frameworks also support client-side rendering. React documents static-site generation support in its recommended full-stack frameworks. A full-stack framework therefore does not automatically mean that every page must use a running application server. Those frameworks allow server-side rendering to be added on individual routes. Decide route by route what content must be generated and when, rather than choosing a deployment model from the framework’s name.
Next.js supports static export without requiring a server. Check the actual features used by your project against its intended hosting arrangement. Record whether the output is a set of static files or requires a server runtime. Keep that decision alongside the project’s build instructions so another developer can reproduce the intended deployment rather than guess it.
React’s from-scratch guide lists Vite, Parcel and Rsbuild as build-tool options. The from-scratch guide explains what that choice leaves to the developer. The listed build tools begin with a client-only single-page application. React’s guide says those build tools do not supply routing, data-fetching or styling solutions. Treat those gaps as work to design, not defects in a starter whose purpose is narrower.
| Starting decision | Suitable question to ask | Evidence for the project record |
|---|---|---|
| Framework | Which application features does it integrate for this project? | Selected framework, version and used features |
| Build-tool starter | Which missing application patterns will we supply? | Routing, data and rendering decisions with owners |
| Static output | Can the selected routes and features use this output? | Build output and a preview of the actual files |
| Server runtime | What must run when a request arrives? | Runtime requirements and deployment instructions |
| Learning prototype | What is intentionally unfinished? | Explicit production work list |
What should the first application actually contain?
Choose a hypothetical equipment directory with a list page and a detail page. Each item has a stable identifier, a name and a short description. Add a search box that filters the list. Use fictional entries so the exercise can be shared without exposing business records.
Draw the screen before adding dependencies. Mark the list, search control, selected item and error message. Decide which values change when the user acts and which values simply describe an item. This sketch gives component boundaries a purpose: each component should make a part of the task easier to understand and maintain.
For this exercise, require a direct URL to an item and a meaningful missing-item screen. Agree what refreshing that URL should do. The choice of router and hosting configuration must support the behaviour you specify; reaching a detail screen by clicking from the homepage is only one of the required paths.
Start with fixture data and then introduce a controlled request boundary. Data fetching requires handling loading states, error states and caching. Describe each state in words before writing its presentation. “Loading” means the request is pending; “empty” means the request succeeded with no matching records; “error” means the intended data could not be obtained. They need distinct actions and messages.
How do you keep the first project manageable?
Make one journey coherent before adding another. A list that displays, filters, opens a detail route and handles missing data teaches more than a larger application whose only reliable state is the homepage. Keep the dependencies you add tied to a written requirement so the starter does not become a collection of unrelated experiments.
React’s documentation explains how build-tool choices expand into routing, data and rendering decisions. Use that explanation to create a responsibility list. Someone should be able to identify which part owns the URL, which part requests the data and which part displays the result. A second developer should not need to read every file to discover those boundaries.
Code splitting breaks an application into smaller bundles loaded on demand. Introduce it when you can describe what is being separated and how it will load. For the directory exercise, a later reporting screen could be evaluated separately from the basic list. Avoid assuming that splitting a file proves a faster user experience; inspect the resulting loading sequence and measure the actual application when performance becomes a decision.
Original route-and-state acceptance card
Use the following card for the fictional directory. These are proposed expected outcomes for the exercise, not results from a built application. Fill in the observed result, evidence and unresolved issue beside each row during review.
List entry: Open the list directly in a clean browser tab. Expect a labelled search field and the fixture records. Capture the URL and visible state. If the application depends on arriving from another page first, record that as an issue rather than changing the test route.
Search: Enter a name that matches a fixture, then a term that matches none. Expect a useful empty-result message with an obvious way to clear the filter. Decide whether the filter belongs in the URL and record the decision. Do not leave browser-back behaviour accidental.
Detail: Open an item through the list, copy its URL and open that URL in another tab. Refresh it. Expect the same item or the agreed access boundary. This case joins routing behaviour to the hosting setup and is essential evidence for any intended shared links.
Missing item: Replace the fixture identifier with one that does not exist. Expect the agreed missing-item response and a useful route back. Keep this case separate from a failed request, because the reader needs a different explanation of what happened.
Request failure: Use an agreed local test condition to make the data request fail. Expect a clear message and a deliberate retry or recovery choice. Record whether the previous data remains visible and whether it is labelled appropriately. A console error alone does not explain the state to the user.
What must be settled before production?
Retain the selected versions, installation command, build command and preview instructions in the project record. Review configuration and secret handling before connecting real services. Specify who owns updates, error reporting, backups for any stored data and recovery from a failed release. A starter does not make those organisational decisions for you.
Use the route-and-state card when asking for a technical review. Its evidence makes a useful distinction between a learning milestone and a production decision. For broader scope, see web development and hosting. To discuss the application, get started with the user journey, rendering decision and outstanding acceptance cases.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.