---
title: "Next.js | Skills We Assign For | Azendo"
description: "Next.js where a product needs both an app and indexable pages — rendering decisions, caching pitfalls and the Azendo roles assigned for it."
url: "https://azendo.co/skills/nextjs/"
---

[Skills](https://azendo.co/skills/) Languages and runtimes 

# Next.js.

Next.js is a React framework that adds routing, server rendering and build tooling on top of React. It is chosen most often where a product needs both application behaviour behind a login and pages that must be fast and indexable in front of it.

## Where Next.js fits on a long engagement.

The reason to use Next.js is rendering strategy. Marketing and documentation pages want to be static and crawlable; a dashboard behind a login does not. Next.js lets both live in one codebase without running two applications, which removes a whole class of duplication.

The cost is that rendering and caching become decisions someone has to own. The failure mode is subtle: a page renders correctly in development, is cached in production, and serves one user's data to another. That is a review-discipline problem more than a framework problem, and it is worth agreeing conventions before the first feature rather than after the first incident.

## What an assigned team does with Next.js.

Rendering decisions are the ones an assigned team carries. Each new route is a small choice about static, server or client, and those choices are individually reasonable and collectively incoherent when made by different people across two years. One owner keeps the model consistent.

Where the pages exist to be found rather than to be used, the constraint is frequently content and structure rather than code, and the useful conversation is with whoever owns that. The build capacity itself is assigned under [software development outsourcing](https://azendo.co/services/software-development/).

## What we use Next.js for.

* A marketing site and an app in one codebase Indexable pages and authenticated application sharing components, deployment and review, instead of two projects drifting apart.
* Improving Core Web Vitals on an existing product Moving work off the client where it does not need to be there, measured on field data rather than a lab score.
* Incremental migration from an older frontend Routes moved across one at a time, with both stacks serving traffic during the transition.

## How Next.js capacity is assigned.

Next.js work is assigned under outsource software development services. Where the rendering question is really an SEO question, that is worth raising at scoping, because it changes who should be assigned. An Azendo [service delivery manager](https://azendo.co/how-it-works/) answers for what that capacity delivers.

## Roles we assign Next.js for

* [Frontend Developer Software development](https://azendo.co/services/software-development/frontend-developer/)
* [Full Stack Developer Software development](https://azendo.co/services/software-development/full-stack-developer/)

## Service lines it sits in

* [Software development](https://azendo.co/services/software-development/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in languages and runtimes

* [Python — skill we assign for](https://azendo.co/skills/python/)
* [Java — skill we assign for](https://azendo.co/skills/java/)
* [TypeScript — skill we assign for](https://azendo.co/skills/typescript/)
* [Node.js — skill we assign for](https://azendo.co/skills/nodejs/)
* [React — skill we assign for](https://azendo.co/skills/react/)
* [R — skill we assign for](https://azendo.co/skills/r/)
* [.NET — skill we assign for](https://azendo.co/skills/dotnet/)
* [Go — skill we assign for](https://azendo.co/skills/go/)

## Tell us what your roadmap needs Next.js for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)