Next.js Maintenance & Support

Most applications do not fail. They drift. The framework moves two major versions ahead, a dependency stops being maintained, the person who understood the caching layer leaves, and one day a routine upgrade is a two-week project nobody budgeted for.

This is the service for teams who have an application in production, do not need a Next.js specialist forty hours a week, and do not want the first specialist conversation to happen during an incident.

What it is not

It is not a retainer that exists to produce an invoice. We will say this plainly because the industry has earned the suspicion: if a month has no work in it, we tell you, and you do not pay for the hours.

It is also not a support desk. You are not filing tickets into a queue. You are talking to the engineers who read your codebase.

What it covers

Framework and dependency upgrades. Next.js and React move quickly. We track what changes, decide what matters for your application specifically, and do the upgrade with the release notes read rather than the version number bumped. A minor that touches your caching behaviour is a different job from one that does not, and knowing which is which is most of the value.

Security and dependency risk. Advisories against your lockfile, triaged against whether the vulnerable path is one your code actually reaches. Most advisories in a Next.js dependency tree are not exploitable in your application; the ones that are, you need to hear about the same day.

Performance regressions. Field data does not stay fixed by itself. A budget enforced in CI catches what a deploy does; a monthly read of Core Web Vitals catches what a CMS change, a new tag or a third party did. The mechanism is the same one we install during performance engineering, and this is keeping it honest.

Incidents. A named engineer who knows your architecture, reachable within an agreed window. The point is not the response time on the contract. The point is that the person who answers has read your code before the incident rather than during it.

The small work that never gets prioritised. A route that should be static and is not. A dependency that could go. The use client that crept up into the layout. Individually none of it justifies a project; together it is the difference between an application that ages well and one that does not.

How it is scoped

A monthly block of hours, agreed in advance, with what they are for written down. Unused hours are unused - we do not invent work to consume them, and we do not roll them forward indefinitely either, because a growing balance is a sign the arrangement is wrong and worth saying so.

Above the block, work is quoted as a project. There is no hourly meter running in the background.

Either side can end it with a month's notice. A maintenance arrangement that needs a contract to survive is not one we want.

What you get in the first month

Before any ongoing work, the same orientation we run on any inherited application: a route map, the data boundary, the deployment path, and the list of what will break next, ordered by when. That document is yours whether or not the arrangement continues. It is the same artefact described in migration and rescue, and it is what makes everything after it cheaper.

When you do not need this

If you have an engineer who reads the Next.js release notes, you do not need us for upgrades. If your application is a marketing site that changes twice a year, an annual review costs less and does the same job.

We would rather say that at the start than bill for a year of nothing happening.