← Back to blog Post

Choosing how to start your React project

Hosted here as an English translation. Originally published on Lean Mind.

The decisions made at the start of a project are critical to its early success. Depending on those choices, we may end up in scenarios that hurt scalability and maintainability, or in situations that accelerate implementation and deployment.

Not every scenario is the same, so there is no universal solution. The important part is not memorizing one technology choice, but understanding the decision process.

The scenario

In this case, the need was a React application that supported custom service workers, consumed a third-party API, produced the smallest bundle reasonably possible, allowed a certain degree of customization, and could still be maintained by people without especially deep expertise.

Before technical analysis

Before selecting a solution, it helps to understand:

  • who will use the application,
  • how comfortable the team is with the technology,
  • and what delivery cadence the product will require.

Team empathy, future flexibility, and business context matter as much as technical features.

Evaluating options

SSR

Because the application was small, authenticated, and did not clearly need indexing, technologies such as Next.js or Remix were ruled out for this particular case. They are powerful, but they also introduce learning curve and a greater risk of accidental framework coupling.

SPA

That left options such as Create React App or building a custom base with tools like Webpack or Vite. CRA is useful in early stages, but once bundle optimization or custom behavior becomes important, the need to eject often appears sooner rather than later.

Bundling

Webpack provides enormous flexibility, but for less experienced teams it can become a significant barrier. Vite, on the other hand, offers faster execution, slightly smaller bundles, and a plugin-based model that tends to be easier to reason about.

Conclusion

Technology evaluation never gives absolute certainty, but it does provide a useful framework for decision making. Some of the relevant criteria here were:

  • where the app will be deployed,
  • which forms of complexity are unnecessary,
  • which learning curve is easier to absorb,
  • which tool offers better maintainability,
  • what level of support and adoption it has,
  • what accidental coupling it introduces,
  • and what impact it has on performance.

The real takeaway is learning how to evaluate the scenario rather than copying a fixed recipe.

  • react
  • frontend
  • architecture