The frontend becomes a system long before teams notice
Early React applications often begin with pages, components and API calls placed wherever they are convenient. That works until the application contains product management, orders, permissions, reporting, booking, POS workflows and tenant-specific configuration.
At that point, frontend architecture affects delivery speed just as directly as backend architecture.
Feature-oriented structure
src/
app/
features/
orders/
api/
components/
hooks/
models/
pages/
products/
pricing/
booking/
shared/
ui/
auth/
api/
utils/Feature ownership keeps code that changes together physically close. Shared folders should contain genuinely reusable capabilities rather than becoming dumping grounds.
Choose server and client boundaries intentionally
Modern Next.js supports an App Router built around newer React capabilities. The useful architectural question is not whether server components are fashionable; it is whether a component needs browser state, effects or interactive APIs.
export default async function ProductPage({ params }) {
const product = await getProduct((await params).slug);
return (
<>
<ProductSummary product={product} />
<AddToCart productId={product.id} />
</>
);
}Do not create one global state object for the company
Server data, URL state, form state, local UI state and cross-session business state are different categories. Treating them all as one global store creates unnecessary coupling.
Permissions belong in a reusable capability
export function can(
permission: string,
userPermissions: Set<string>
) {
return userPermissions.has(permission);
}Menus, buttons and routes can reuse the same permission utility, while the backend remains the authoritative security boundary.
A design system is delivery infrastructure
Buttons, fields, data tables, modals, spacing, typography, status indicators and feedback patterns should not be redesigned on every screen. A controlled design system lets engineers build business workflows instead of repeatedly solving visual primitives.
Business value
Why it matters to the business
- Faster feature delivery as the application grows.
- More predictable UI behaviour across admin, POS and customer applications.
- Lower onboarding cost for new frontend engineers.
- Better accessibility and consistency through reusable primitives.
- Cleaner migration path when frameworks evolve.
Practical considerations
- Requires ownership of shared components.
- Teams need rules for what belongs in shared versus feature code.