Flexible Next.js developers for project work

Why Next.js work comes in waves

Next.js is among the fastest-evolving frameworks. Version 16 Turbopack became the default, Cache Components introduced a new caching model, and the previous Middleware is now called Proxy. If you’re coming from version 14 or 15, or still on the Pages Router, you face an upgrade that’s more than a new version number in package.json.

There are also security updates that don't wait for your sprint planning. On September 22, 2026, the Next.js team unexpectedly released versions 16.3.6 and 15.5.26 to fix a critical vulnerability in an upstream dependency To conclude: Such updates must be applied and tested promptly, even if no one on the team currently has time for them.

The result is demand that fluctuates significantly. Sometimes you need full capacity for two months, then only a few hours a month. Flexible project work is well suited for this type of demand.

Five initiatives well suited to scope as projects

Migration from the Pages Router to the App Router

The App Router brings Server Components, nested layouts, and streaming. The migration doesn’t have to be a big bang. Both routers can run side by side in one application so you can move route by route and test each stage individually. An experienced Next.js developer starts with pages that have high traffic and little logic, leaving complex areas like checkout or customer accounts for later.

Upgrade to the current Next.js version

This covers Turbopack as the standard build tool, the new Cache Components model, and renaming Middleware to Proxy. The old Middleware continues to work for now but is deprecated. A clean upgrade first checks your dependencies, then switches the build, and finally adjusts caching—because that's where most surprises hide.

Performance sprint with Core Web Vitals as the goal

Slow pages cost you users and visibility. Google rates a page as good when the largest content is visible within 2.5 seconds, input response stays under 200 milliseconds, and the layout barely shifts. A Performance Sprint first measures using real user data, identifies the biggest bottlenecks, and fixes them in a clear order.

Headless commerce or a frontend for a CMS

Many shops now separate backend and frontend. Product data comes from a system such as Medusa, Shopify, or a headless CMS, with the frontend built in Next.js. The project has a clear start and end; afterward, a small hour bundle is usually sufficient for maintenance.

Updates and security as an ongoing routine

Not every project is large. Sometimes the task is to update dependencies once a month, review security notices, and apply updates. It’s not glamorous, but it prevents a small update from turning into a migration across three versions.

How to shape a Next.js project so it stays predictable

Flexible project work is most effective with clear boundaries. What seems contradictory has a simple reason: the more precisely the goal is defined, the more freedom you have on scope and pace.

• A measurable goal. Rather than “the site should be faster,” prefer “product pages achieve a good Largest Contentful Paint on mobile.”
• A timeframe. Set a framework—for example, six weeks with 150 hours per month—then schedule a meeting to decide how to proceed.
• Visible interim results. At the end of each sprint, there’s something you can click—not just a report.
• A list of what doesn’t belong. Write down what is explicitly not part of the project. That list prevents more disputes than any contract.

With a project scoped like this, you can change course midstream without renegotiating everything.

What a Next.js developer should be able to do in 2026

Next.js is quick to learn and hard to master. The following points separate someone who followed tutorials from someone who runs applications in production.

• Separate Server and Client Components cleanly, and know when a component needs to run in the browser.
• Understand caching—from static pages and revalidation to Cache Components.
• Secure Server Actions with validation and permission checks, because they can be invoked from outside.
• Run applications without Vercel, for example on your own Node server or in containers.
• Finding production errors via logs and tracing is guesswork.
• TypeScript in strict mode, so data from forms, APIs, and the database is cleanly typed

You can read about the topics we see most often in projects on that page: Hire Next.js developers. For the fundamentals, see the page on React developers.

Typical pitfalls we find in existing applications

When we take over an existing application, certain patterns always reappear. None are a crisis, but each costs time, money, or security if left unaddressed.

• Waterfalls when loading data. Nested components wait for their data sequentially instead of loading in parallel. The page feels sluggish even though each request is fast.
• Too much code in the browser. A single “use client” high in the tree turns whole areas into Client Components. The bundle grows, and the benefits of Server Components disappear.
• Guesswork caching. Sometimes the site shows outdated prices; sometimes nothing is cached. Usually, there's no documented rule for which data is valid for how long.
• Secrets in the frontend. Environment variables with the NEXT_PUBLIC prefix end up in the code every browser downloads. An API key does not belong there.
• Server Actions without checks. An action that doesn’t itself control who calls it is an open door, even if the button is visible only to admins.

A short assessment at the start of a project uncovers such issues within a few days. After that, you decide what is fixed immediately and what moves into the normal workflow.

Flexible does not mean arbitrary

Flexibility is an advantage for Next.js projects as long as one thing stays stable: the person. Whoever migrated your application knows its rough edges. If a different developer handles each update, you pay for onboarding every time.

That’s why we recommend a simple pattern. In the intensive phase, a dedicated developer works on the monthly plan with 150 hours. Afterward, they switch to an hour bundle, and ideally the same person remains responsible with a few hours per month for updates and minor changes. Bundles start at 80 hours; all models are available in the Pricing overview.

If your own team should continue running the application later, plan the handover from the start. A few joint sessions in which your people implement changes themselves while the external person only sits next to them are worth more than any document.

Clarify hosting and dependencies early

Next.js runs most conveniently on Vercel, but not exclusively. Many companies in Austria and Germany prefer to run their applications in an EU data center or on their own infrastructure. That works well, but requires a few deliberate decisions.

• Which functions depend on the platform, for example image optimization, revalidation, or edge functions?
• Where is the cache located when multiple instances are running?
• How does the business unit get previews of new builds?
• Who applies security updates, and how quickly?

A good Next.js developer documents these points so you can change providers later without having to rebuild half the application. DevOps Engineer during setup.

What a project plan can look like

An example migration from the Pages Router followed by an upgrade to the current Next.js version, intended for a mid-sized application with marketing pages and a customer area.

The example is deliberately simplified. How long it takes for you depends on the size of the application and the test coverage. An assessment in the first two weeks makes the estimate for the rest much more reliable.