Enterprise Next.js Development

"Enterprise" is usually an adjective on a sales page. Here it means a specific set of constraints, and if none of them apply to you then application development is the same work without the overhead.

These are the constraints we mean.

Identity that your IT department already runs

SSO against the directory you have - Entra ID, Okta, Google Workspace, or a SAML provider nobody has upgraded since 2019. SCIM provisioning so leavers lose access when HR says they left, not when someone remembers.

Role mapping comes from the directory's groups rather than a table in your application, because the moment your app owns the roles, two systems own them and they drift. Sessions are short and refresh server-side; the token never reaches the browser.

Data that has to stay where you said it would

Your customers' contracts say where their data lives, and a platform's default region is not an answer to that. Self-hosting is the usual conclusion: output: 'standalone' in a container, in your cluster, in your region, beside your database.

That path has four specific costs, and we cover them rather than discovering them - image optimisation, a shared cache for revalidation across replicas, middleware that no longer runs at the edge, and a proxy that must not buffer streaming responses. It is written up in full in self-hosting Next.js, and what stops working.

Evidence, because someone will ask for it

Audit trails on the mutations that matter, with the actor, the before and the after. A Content Security Policy with a nonce rather than unsafe-inline. Dependency provenance in the build, so a supply-chain question has an answer. Accessibility tested rather than asserted, because public-sector and large-enterprise procurement asks for a statement and someone eventually checks it.

None of this is exotic. It is all much cheaper to build in than to add after a security review has produced a list.

Working inside your process

We work in your repository, against your branch policy, with your review gates. Not our repo handed over at the end, and not a parallel process that your platform team has to learn.

Where you have a design system, we build against it. Where you have a platform team, they are in the pull requests from the first week, because the measure of this work is whether your engineers can keep it after we are gone - which is the same standard as code you can keep, applied to an organisation rather than a team.

What slows these projects down

Honestly: not the engineering. It is waiting on a staging environment, on directory access, on a security questionnaire, on the one person who can approve a firewall rule.

We plan around that rather than pretending it will not happen. Phases are scoped so that a blocked dependency stops one phase and not the project, and we will tell you in week one which approvals to start early, because they are usually the critical path.

The other recurring one is the system of record. An application at this size almost always has to show figures that live somewhere else - a ledger, an ERP, a warehouse system - and where that boundary is drawn decides more about the project than the framework does. Which parts of an integration belong in the application and what to do when the other system has no public address are the two shapes that conversation takes.

How an engagement runs

Procurement first, because it has the longest lead time. Tell us at the start which agreements, questionnaires and reviews apply, and we work through them while the scoping happens instead of after it.

The scope is written and priced before anything is built, and it names the identity provider, the residency constraints and the evidence you will have to produce later. That document is what the contract attaches to, so the security review and the build are reading the same description.

Then delivery in phases, in your repository and your review process, with handover treated as a scheduled phase and not a final email.

What you receive

The application, plus the artefacts your organisation asks for after it ships: the architecture document, the SSO and permission mapping written out, the data-residency decisions with what each one constrains, and the audit trail specification.

Handover is scheduled work rather than an email at the end. Your platform team gets a walkthrough and the runbook, and we treat the engagement as finished once they have deployed it themselves with nobody from us in the room.