10-Point Checklist Before Deploying Your First React App

Your app works on localhost. Buttons click, data loads, the layout holds. Then you deploy, open the URL on your phone, and something small is wrong: a blank page on refresh, a spinner that never stops, or a key you thought was hidden sitting in plain text inside the JavaScript bundle.

Those failures are ordinary. They come from a handful of things that development mode quietly hides from you. Work through the ten points below and you will catch most of them in an afternoon, without adding new tools to your stack.

1. Test the Production Build, Not the Dev Server

The dev server is generous. It compiles on demand, keeps helpful warnings, and skips the minification and tree-shaking your visitors will actually receive. Before you deploy, run the real build (npm run build) and serve the output locally, either with your framework's preview command or a simple static server.

Click through every route in that build. The console will be quieter, but your own console.log calls and leftover debug code ship to users exactly as written. Watch for the classic layout bug: an image that renders from src/ in development but 404s in production because the path is wrong or the filename case does not match. macOS forgives ./Button versus ./button. The Linux container that builds your site does not.

2. Know What You Are Shipping

Open the build output and read the file sizes. A JavaScript bundle that crosses into multiple megabytes means a slow first paint on a phone, especially on a patchy connection. If the numbers surprise you, run a bundle visualizer against your production build and look at what dominates the output.

These imports show up again and again:

• A whole utility library imported for one or two functions, when a named import or a short helper would do.
• An icon package imported by the bundle rather than icon by icon.
• A heavy date library when the built-in Intl formatting covers your needs.
• Two copies of React because two dependencies disagree about versions.
• Full-resolution photos dropped straight into src/ with no compression.

Split the heavy routes with React.lazy and Suspense, compress images, and lazy-load anything below the fold. Measure before you optimize, and re-measure after.

3. Build the States You Never Designed

Most first-time React apps handle exactly one state: success. Real users meet the others. Every screen that fetches data needs at least four:

• Loading — a skeleton or spinner that appears immediately, not after a delay.
• Empty — a useful message for "no results yet" instead of a blank panel.
• Error — what went wrong and a retry button, not a silent failure.
• Long content — a 90-character username or a 40-row table, rendered without breaking the layout.

Wrap the app in an error boundary so one broken component does not blank the entire page. Then test the failure paths on purpose: throttle the network to slow 3G in DevTools, switch to offline mode, and return a 500 from your API. If your fetch calls sit inside a try/catch that swallows errors, add a visible message to the user.

4. Treat Everything in the Frontend as Public

Anything your React app can read, a visitor can read. Variables prefixed with REACT_APP_ or VITE_ are compiled into the published files, so a private key placed there is not private. Search your built bundle for the words key, secret, and token before you deploy.

If a paid API needs a secret, route those requests through your own backend and keep the key there. Restrict keys by domain or referrer where the provider allows it. Keep .env files out of version control, and rotate anything that has already been committed or deployed.

While you are in this frame of mind: run your dependency audit and fix what it flags, avoid dangerouslySetInnerHTML with user-supplied text, and confirm your API allows requests from your production domain. A forgotten CORS setting produces the most confusing launch-day bug of all: everything works locally, nothing works live.

5. Check Responsiveness on a Real Device

Resizing a desktop window is not the same as holding a phone. Emulation misses touch targets, the dynamic browser chrome that changes the usable viewport height, and the on-screen keyboard that slides over focused inputs. Test on at least one actual phone, in both orientations.

Look for the usual offenders: a long email address or URL pushing a card wider than the screen, a modal taller than the visible area with no way to scroll, tap targets thinner than a fingertip, and focus outlines removed without a replacement. Scroll sideways on every page; any horizontal scroll means something overflowed. Then zoom the page to 200% and check that nothing important gets clipped.

6. Get the Hosting Details Right

A single-page app needs a rewrite rule. Without one, refreshing /dashboard asks the server for a file that does not exist and returns a 404. Netlify reads a _redirects file, Vercel and nginx have their own equivalents, and most static hosts document the pattern. Set it up before you share the link with anyone.

Then check the rest of the plumbing: the build command and output directory, the environment variables set in the host dashboard rather than a committed file, and the Node version your build runs on. Confirm HTTPS is active, decide whether the www and apex domains both resolve, and give genuinely missing URLs a real 404 page rather than a blank screen. Finally, set a page title, description, and favicon so shared links do not look abandoned.

Run the Ten-Point Pass

1. Build for production and click through every route locally.
2. Read the bundle sizes and split whatever is heaviest.
3. Handle loading, empty, and error states on a throttled connection.
4. Confirm no secrets appear in the published JavaScript.
5. Fix the dependency audit warnings you can act on now.
6. Test on a real phone, portrait and landscape.
7. Add the SPA rewrite so refreshes do not 404.
8. Set environment variables in the host, not in the repo.
9. Check HTTPS, favicon, title, and the 404 page.
10. Deploy to a preview URL first, then promote to production.

Your first deployment is not the finish line, it is the moment real traffic starts telling you things. Keep the previous deploy one click away so a rollback takes seconds, watch the browser console and network tab on launch day, and fix the first real bug you find. That habit matters more than any single item on this list.

Photo: borevina / Pixabay