React
React development for product interfaces
We build React interfaces for products and portals where the team wants a component model and a large hiring pool. Next.js is used when server rendering or a disciplined routing model helps the product. Business rules stay on the server.
- Application shells
- Dashboards
- Portals
- Next.js when it helps
What we build
SaaS application shells, customer portals, and operational dashboards. Data fetching, error states, and permissions are designed with the API. A React app that hides prices or buttons only in CSS is not a permission model, and we will not ship it as one.
React, Angular, or Vue
React fits product teams and design-system heavy UIs. Angular fits large form-and-workflow applications, especially if the team is already there. Vue fits incremental adoption and teams that want a lighter structure. The pages for each say so without pretending one of them won.
React for a product interface
React when
- A web app with signed-in users
- A component set you will keep
- A team that can maintain it
Not required
- A simple content page
- A native phone app by default
- A rewrite of a calm admin
What changes a React app
The data
The server still owns the rules. React owns the screen.
The kit
We pick a small set of libraries and stick to them.
The states
Empty, loading, denied, and error are part of the first release.
Before a React app
- 01
Signed-in users
Who they are, and the role that changes the screen.
- 02
The server
Who owns the rules. React owns the screen.
- 03
The states
Empty, denied, and error, not only the happy path.
- 04
The keepers
Who will add the next screen.
Marks React is a product surface
- 01
A product, not a page
It is a signed-in interface with state, not a handful of marketing pages.
- 02
State matches the record
What the screen shows can be reconciled with the server.
- 03
Not for a brochure
A content site without an application was pointed at a simpler front end.
- 04
States are visible
Loading, empty, and error are designed, so build is not inventing them.
What we build
Application shells
Navigation, roles, and the states a long-lived product needs.
Dashboards
Views with defined metrics and a path to the underlying record.
Portals
Customer or partner tasks that share the API with other clients.
Next.js when it helps
Public pages that must load and be indexed, beside the logged-in product.
Questions we hear
Do you use TypeScript with React?
Yes for new work.
Can you take over a React codebase?
Yes, after we see how data and auth are handled. A rescue often starts by making those two boring.
Is this website React?
No. This marketing site is Angular. We use both, and we pick per product.