React makes it easy to start building. That is its strength - and its trap. A prototype comes together in days, the demo looks great, and then six months later every new feature takes twice as long, the app stutters on phones and one developer is afraid to touch the checkout screen.
These problems are rarely caused by React. They come from a set of recurring decisions - or non-decisions - made early in the project. Here are the ones we see most often when businesses ask us to review or take over an existing React application, with what to do instead.
1. Starting without a framework or a plan for rendering
Older projects were often started with Create React App, which the React team has officially deprecated. Others are bare client-side setups even though the product has public pages that must rank on Google.
What to do instead: Decide early which pages are public and need server rendering or static generation, and use a framework such as Next.js for those. Client-side rendering is fine for pages behind login. Read our explainer on React and SEO for the details.
2. Skipping TypeScript
Plain JavaScript lets a developer pass the wrong kind of data from one component to another, and nothing complains until a user hits the bug. In a growing team this becomes a constant source of regressions.
What to do instead: Use TypeScript from the first commit. It documents what every component expects, makes refactoring safer and dramatically shortens onboarding for new developers.
3. Putting all state in one giant global store - or none at all
Two opposite mistakes produce the same mess:
- Everything in a global store, so every small change triggers updates across the app.
- No structure at all, with data passed down through many layers of components ("prop drilling") and duplicated in several places.
What to do instead: Separate the kinds of state.
| Kind of state | Example | Sensible home |
|---|---|---|
| Server data | Orders, products, user profile | A data-fetching library such as TanStack Query, or server components |
| Global UI state | Logged-in user, theme, language | React context or a small store like Zustand |
| Local UI state | Is this dropdown open? | useState inside the component |
| URL state | Filters, page number, search query | Query parameters in the URL |
| Form state | Field values and validation | A form library such as React Hook Form |
Putting filters in the URL has a business benefit too: customers can share or bookmark a filtered product list.
4. Shipping huge JavaScript bundles
Every library added "just for one feature" - a full charting suite, a date library with every locale, an icon pack with thousands of icons - ends up in the bundle that every visitor downloads. On mid-range Android phones over mobile data, which is how a large part of India browses, this shows up as slow loading and laggy taps.
What to do instead:
- Review bundle size regularly with an analyser tool.
- Lazy-load heavy screens and components that are not needed immediately.
- Import only the parts of a library you use.
- Prefer server components or server rendering so less code reaches the phone.
- Question every third-party script, including chat widgets and duplicate analytics tags.
5. Unnecessary re-renders everywhere
React re-renders components when their state or props change. Badly structured components can cause an entire page to re-render when someone types a single character in a search box.
What to do instead: Keep state as close as possible to where it is used, split large components, and use memoisation selectively where profiling shows a real problem. The React Compiler, introduced by the React team to automate much of this memoisation, can help in newer projects - but good component structure is still the foundation.
6. Fetching data inside effects without handling loading, errors and races
A very common pattern: fetch data in useEffect, set it to state, done. What is missing is everything that happens in real life - slow networks, failed requests, the user switching tabs before the first request finishes, duplicate requests and stale data.
What to do instead: Use a dedicated data-fetching approach (server components, or a library such as TanStack Query) that handles caching, retries, loading and error states consistently. Design proper empty, loading and error screens with your UI/UX design team rather than leaving a blank page.
7. No component system
When every developer builds their own buttons, inputs and modals, you get five slightly different buttons, inconsistent spacing and accessibility gaps.
What to do instead: Build or adopt a small design system early: a shared set of buttons, form fields, cards, modals and typography, documented in one place (Storybook is a popular tool for this). New screens become faster to build and the product looks consistent.
8. Ignoring accessibility
Clickable divs instead of buttons, missing form labels, images without alt text and colour contrast that is hard to read - these exclude users and also make automated testing harder.
What to do instead: Use semantic HTML elements, label every form field, make everything usable with a keyboard and check contrast. Accessible components are also easier for search engines and testing tools to understand.
9. No automated tests
Without tests, every release is a gamble, and developers become reluctant to improve old code. That is how codebases rot.
What to do instead: You do not need full coverage. Focus on:
- Unit tests for important business logic - price calculations, GST computation, eligibility rules.
- Component tests for key interactive pieces such as forms.
- End-to-end tests with a tool like Playwright or Cypress for critical journeys - sign-up, login, checkout, payment via Razorpay or UPI.
Run them automatically on every change before deployment.
10. Secrets and business logic in the front end
Anything shipped to the browser can be read by anyone. We still find API keys for paid services, admin-only endpoints and pricing or discount logic sitting in front-end code.
What to do instead: Keep secrets on the server. Treat the front end as untrusted: every permission check, discount rule and validation must also be enforced in the back end. Our Node.js team designs APIs with this in mind.
11. Letting dependencies age for years
React projects depend on dozens of packages. Leave them untouched for two or three years and an upgrade becomes a project in itself, while security fixes pile up.
What to do instead: Schedule small, regular dependency updates, run security audits, and keep React and your framework on supported versions. This is part of what good website maintenance covers.
Major React versions also introduce changes - React 19, for example, removed some long-deprecated APIs. Teams that update regularly handle these as small, planned tasks; teams that wait years face them all at once, often alongside framework and library upgrades.
A quick health check you can run on your current app
| Question | Healthy answer |
|---|---|
| Is the project in TypeScript? | Yes, with strict settings |
| Are public pages server-rendered or static? | Yes, where SEO matters |
| How are Core Web Vitals in Search Console? | Mostly "good" on mobile |
| Are there automated tests for checkout/login? | Yes, running on every deployment |
| When were dependencies last updated? | Within the last few months |
| Is there a shared component library? | Yes |
| Are any API keys in the front-end code? | No |
| Do you have full repository access? | Yes |
If you answered "no" or "not sure" to three or more, the app would benefit from a structured review.
Key takeaways
- Most React problems come from early structural decisions, not from React itself.
- Use a framework and plan rendering per page, especially for SEO.
- Adopt TypeScript, a clear state strategy and a shared component system from the start.
- Watch bundle size and test on mid-range phones over mobile data.
- Never trust the front end with secrets or business rules.
- Automated tests and regular dependency updates keep the product healthy for years.
Is your React app slowing down your team or your users? Book a free consultation and our developers will review the codebase and share a practical improvement plan. See our React JS development services for new builds and takeovers.
