Any agency can list React on a services page. The difference shows up eighteen months later, in how the application handles state, caching and rendering under real traffic, and in whether your own team can take the codebase over without us. Here is how we make those calls, and where we would tell you to hire someone else.
State management: the choice that ages worst
Most React codebases rot at the state layer, and the usual cause is treating server data as client state. An API response gets copied into a Redux store or a Context provider, and from that moment the app owns a stale duplicate of your database. Every bug after that is a synchronisation bug. We split the two on day one. Server data lives in a cache with a key, a staleness policy and an invalidation rule (TanStack Query on the client, the fetch cache and revalidateTag on the server). Client state is only what the server can never know: open modals, unsubmitted input, the current step of a wizard. After that split, most applications need far less machinery. React Context is a dependency injection mechanism, not a store: put a frequently changing value in it and every consumer re-renders, which is how a reasonable looking theme provider ends up re-rendering a long table on every keystroke. Zustand or Jotai handle genuine cross-tree client state with selector level subscriptions. Redux Toolkit still earns its place for time travel debugging, a strict single mutation log, or an offline queue that has to replay in order. When a project has none of those, we say so instead of installing it anyway. The wrong call here is invisible in month one and surfaces when the fifth developer cannot work out where a value is written.
Server Components, the client boundary and cache invalidation
The hard part of the App Router is not the syntax, it is drawing the client boundary. The 'use client' directive is not a per component label, it is a cut in the module graph: everything imported below it ships to the browser. We have inherited projects where one directive at the top of a layout pulled the whole tree into the client bundle while the team still called it a Server Components app. The discipline is to push the boundary as far down as possible: the server component fetches and renders, a small client leaf owns the interactivity, and anything crossing the boundary stays serialisable. Then comes invalidation, where most Next.js applications quietly go wrong. Caching is layered (request memoisation, the data cache, the full route cache, the client router cache) and each layer evicts on its own terms. A mutation that writes to Postgres, returns success and never calls revalidateTag leaves users staring at last week's data with no error logged anywhere. We tag fetches by domain entity, invalidate from the server action that performed the write, and treat any read we cannot invalidate deterministically as dynamic. Paying for a dynamic render is cheaper than serving a stale price to a paying customer. Optimistic updates follow the same logic: fine on a comment box, dangerous on anything financial.
A rendering strategy per route, and the bundle discipline that keeps it honest
Rendering is a per route decision, not an application wide setting. A marketing page should be static and revalidated when content is published. A catalogue with facets is usually a static shell with streamed data. An authenticated dashboard has no business being prerendered at all. One mode for everything means paying for compute on pages that never change, or serving cached HTML to a logged in user. Bundle discipline is the other half of the job. React's real cost is not download size, it is hydration and interaction latency: a page can score well on paint metrics and still feel broken because a single long task blocks the main thread for hundreds of milliseconds when someone taps a filter. The offenders are predictable. Barrel file imports that defeat tree shaking. A date library pulled in whole for one format call. A rich text editor or a charting package loaded eagerly on a route that hides it behind a tab. Third party marketing tags that outweigh the entire application. Two copies of the same dependency because a package pinned its own. We set a bundle budget per route, load heavy widgets through dynamic imports, watch interaction latency rather than only a Lighthouse score, and assert the numbers in CI so a regression fails the build instead of reaching production.
Accessible components, tests worth running, and a handover you actually own
Custom components are where accessibility usually breaks, because the browser stops helping you. A div with an onClick has no role, no keyboard activation, no focus ring and nothing to announce. Rebuilt select menus lose keyboard type ahead. Hand rolled modals leave focus behind and let keyboard users tab straight into the page underneath. We build interactive primitives on a headless library that already implements the accessibility contract (Radix or React Aria), then test with the keyboard alone, which catches more than any automated scanner. Testing follows the same principle: behaviour, not implementation details. React Testing Library for component behaviour, Playwright for the small number of flows that actually generate revenue, and typed contracts at the API edge so a renamed backend field fails at compile time rather than in a user's browser. We do not chase a coverage percentage: a suite that asserts on internal state breaks on every refactor and teaches the team to delete tests. Every change goes through a written pull request review, so the reasoning behind a decision is still readable a year later. At handover you receive the repository, the environment variables, the deployment pipeline and the third party accounts, all in your name. The code is yours, the domain is yours, and nothing we build requires a subscription to us.
When React is the wrong answer, and when we are the wrong agency
React is the wrong tool far more often than agencies admit. A brochure site for a restaurant, a law firm or a portfolio is a job for static HTML, Astro, Eleventy or a well configured CMS. A React application there buys you a build step, a hydration cost and a dependency treadmill in exchange for nothing a visitor will ever notice. Conventional ecommerce with a standard catalogue, cart and checkout is usually better served by Shopify than by a custom storefront you then maintain through every payment and tax change: you pay a monthly plan (the entry tier sits in the low tens of dollars a month at the time of writing, and plans change) plus processing on each order, and in return you never write a checkout. If your team publishes content daily and nobody writes code, a headless stack can be a downgrade dressed as an upgrade. There are also cases where we are the wrong agency. If you need people on site, or a weekly call, or someone reachable within the hour, that is not us: we work in writing, with a reply inside 24 business hours. If you need eight engineers next month, a native iOS and Android team, or a supplier who can survive a nine month enterprise procurement process, hire a larger firm. If you already have a strong in-house React team and only need extra hands, staff augmentation will serve you better than an agency engagement. We would rather write that now than discover it three weeks in.
How two people in Dijon work with a client eight time zones away
We are two founders in Dijon, France. Robin Monteiro builds (full stack, Next.js and React) and Florian Loppion handles the marketing side. You deal directly with whoever is doing the work: no account manager relaying your requirements to a developer you never meet, no bench of juniors behind a senior name on a proposal. Everything runs in writing, by email. We take no calls and no video meetings, and for an international client that is an advantage rather than a concession. A founder in California never takes a 3am call. A team in Bangalore is not waiting for a European afternoon to get unblocked. Work moves while you sleep: you send context at the end of your day, an answer is waiting inside 24 business hours, and the decision arrives written down rather than half remembered from a call nobody recorded. Six months later, when someone asks why checkout skips address validation for one country, the answer sits in a thread you can search. What changes for you is real: requirements have to be written down. A screenshot with an arrow on it, a short screen recording, a numbered list of what is wrong. That effort is front loaded, and in exchange there is no meeting overhead, no recap email, no argument about what was agreed. Clients who think out loud and need someone on the other end tend to dislike this, and that is a fair reason to pick another agency.
