React where it earns its place
We build React interfaces for the screens that genuinely need them, and we maintain React applications other teams started. We will also tell you when your project does not need React at all.
What we do with React
React is a library for building user interfaces out of components whose appearance follows from their state. That is a genuinely good idea for screens where a lot changes without the page reloading, and an expensive one for screens where nothing does.
Interactive screens inside a larger application
A scheduler, a builder, a configurator, a dashboard with live filters. We drop React in for that one screen and leave the rest of the application server-rendered.
Maintaining and extending existing React apps
Feature work, dependency upgrades, test coverage, and untangling state management that grew faster than anyone planned.
Accessibility work on React interfaces
Custom components are where keyboard support and screen reader announcements go missing, because React gives you a div and no opinion about what happens next. Focus management after a route change is the one almost everyone misses.
Component libraries
Turning a design system into reusable, documented, tested components so your team stops rebuilding the same button four different ways.
When React is the right call, and when it is not
Good fit: the interface is the product
Drag and drop, live collaboration, complex forms that change as you fill them, data views with many interacting controls. If the state is genuinely complicated, React makes it manageable.
Good fit: you already have a React team
Consistency with the people who will maintain the thing beats our preferences every time.
Not a fit: a marketing or content site
Rebuilding a content site in React usually makes it slower on the phones your customers actually use, adds a build pipeline, and turns search visibility into a problem you have to solve rather than one you get for free.
Not a fit: mostly forms and pages
Most business applications are lists, forms, and detail views. Server-rendered pages with a little JavaScript are faster to build, cheaper to maintain, and accessible by default. That is what we reach for first.
Watch out: two applications instead of one
A React front end talking to an API means two codebases, two deploys, two sets of dependencies, and a boundary to keep in sync. That is a real ongoing cost, and worth paying only when the interface demands it.
How we usually mix React with the rest
Our default is a server-rendered Ruby on Rails application with React used as an island on the screens that need it. The list pages, forms, and reports stay simple and fast. The scheduler or the configurator gets the tool built for that job.
You end up with one codebase, one deploy, and complexity only where you are getting something for it. When a client already runs a full React front end, we work in that instead. The point is matching the tool to the screen rather than to a preference.
Questions we get about this
- Do we actually need React for our project?
-
Often not, and we will say so before you spend the money. React is worth its cost when the interface itself is complicated: drag and drop, live collaboration, configurators, forms that reshape as you fill them.
Most business software is lists, forms, and detail views. Those are faster to build, cheaper to maintain, and accessible by default as server-rendered pages with a little JavaScript. Our usual answer is to use React for the one screen that needs it and keep the rest simple.
- Can you take over a custom application someone else built?
-
Sometimes. We need read access to the codebase first. Once we've looked at what's there, we can scope what it would take to stabilize it and continue the work. Sometimes the right path is to keep going on what exists. Sometimes it's a rebuild. We'll tell you which, and why, before any work starts.
- Are React interfaces accessible?
-
Only if someone makes them accessible. React renders whatever you tell it to, so a custom dropdown or modal starts with no keyboard support and no screen reader announcements until you add them.
The failure almost every React application shares is focus management after a route change, where a screen reader user is left at the top of a page with no idea anything happened. We test with a keyboard and a screen reader rather than trusting a component library's marketing.
- What platforms do you support?
-
All of them, in the sense that we've worked across most major and a lot of niche ones. We're most experienced with WordPress, Shopify, and custom Ruby on Rails applications. If your stack is something we haven't worked in before, we'll tell you that on the consultation, and we'll be honest about whether we're the right fit.
Been told you need a React rebuild?
Get a second opinion before you commit the budget. In a free consultation we will look at what the interface actually has to do and tell you whether React is the shortest path or an expensive detour.