We've been shipping React Server Components in production since they hit stable. After eighteen months and a dozen projects, RSC is real — but it's also nothing like the marketing. The teams that succeed treat it as a serious architectural change. The teams that fail bolt it onto their existing app and wonder why nothing works the way the docs implied.
Where RSC genuinely shines
Content-heavy pages with little interactivity are the obvious win. Marketing sites, documentation, dashboards where most components are read-only — RSC reduces bundle size by 40 to 70% in our typical project, and the data-fetching colocation is a real productivity gain.
Long lists with mixed data sources are the less-obvious win. Server components can fetch from three databases in parallel, render, and stream — without the client knowing or caring. That pattern was awkward in every prior React era.
Where it hurts
The component tree's server/client boundary leaks into your code. Once you accept that, the rest is fine. If you fight it — passing functions across the boundary, trying to share state — you'll spend a week per attempt before you give up and refactor.
Third-party library compatibility is the second sharp edge. Anything that uses React Context, hooks, or browser APIs needs a 'use client' wrapper. We maintain a small internal shim layer for the worst offenders.
Patterns we've evolved
Keep the server component shell as thin as possible. Push interactivity into leaf client components. Treat 'use client' as a deliberate boundary, not a workaround. And ship a measurable bundle-size budget — RSC's biggest payoff is the kilobytes you don't ship, but only if you watch them.
Want this kind of work on your project?
One conversation, honest pricing, recommended engagement model — within a business day.
Keep reading
All articlesHow we estimate software projects (and why most estimates are wrong)
Every estimate is wrong. The useful ones are wrong in known ways. A practical method we've refined across 50+ engagements — and the failure modes we learned to spot first.
The unreasonable effectiveness of plain SQL
ORMs are fine. Until they aren't. After a decade of building data layers on every framework we could find, we keep coming back to plain SQL — and the patterns that make it pleasant.
Why we don't write microservices anymore
We split into microservices because it was 2019. Then we spent three years feeling the cost. Here's what we learned, and how we structure backends in 2025.