What is the difference between a Next.js developer and a React developer?
React is a library for building UI components; Next.js is the meta-framework around it, providing routing, server-side rendering, static site generation, image optimisation, edge functions and an opinionated project structure. Every good Next.js developer is also a React developer, but the reverse doesn't automatically hold. When SSR, SEO or a mixed rendering strategy is needed, you should specifically look for Next.js experience; for a purely client-side dashboard, vanilla React is sufficient.
Do you work with the App Router or the Pages Router?
The App Router has been stable since Next.js 13 and, since version 14, is the recommended approach for new projects — with server components, server actions and a clearer split between server and client code. We build new applications in the App Router by default. For existing Pages Router projects, we carry out a phased migration where the business case justifies it, or we maintain the Pages Router codebase perfectly well without a forced migration. We don't force a rebuild where it isn't necessary.
SSR, SSG or ISR — how do you choose?
We determine the rendering strategy per route. SSG for pages with content that rarely changes, ISR for pages that need periodic or on-demand revalidation (product pages, case studies, blog), SSR for pages that depend on the user or live data on each request, and client-side rendering for interactive dashboards after login. It isn't an all-or-nothing choice; within one application we mix these patterns at route level to balance performance and data freshness.
Vercel or self-hosted — what do you recommend?
Vercel is the path of least resistance for a Next.js application, offering preview deployments, edge functions and image optimisation out of the box. For many clients, that is the right choice. For organisations with strict data residency requirements, their own Kubernetes platforms or a cost structure that favours hosting at scale, we deploy Next.js via Docker on AWS, GCP, Azure or your own platform: standalone builds, image optimisation via a proxy or a third-party optimiser, and edge functions replaced by a custom CDN layer. We discuss the scenario candidly upfront; we have no dogma about Vercel.
What is the minimum lead time to bring in a Next.js developer?
For a team augmentation role we can often have someone start within a few weeks, depending on the required stack mix and seniority level. For a project-based engagement with a scoping phase it takes a little longer, as we first produce a scope document and sprint plan. We will be candid during the introductory call about what is realistic for your timing.
Which contract models do you offer: fixed or flexible?
Both are possible. For a dedicated developer or team augmentation, we work on an hourly rate with a minimum weekly commitment, cancellable monthly. For project-based scope, we agree a fixed contract based on a scope document with deliverables and a sprint budget. No multi-year lock-ins and no mandatory minimum contract term measured in years.
Do you work with a Dutch team?
The Next.js team works from the Netherlands, in the Dutch time zone. Communication can be in Dutch or English, whichever you prefer. No offshore handover, no 24-hour cycles, and no language barriers in pull request reviews or stand-ups. If a production incident occurs, someone is immediately reachable within working days, without time-difference delays.
What happens if the developer leaves halfway through the project?
That is precisely why we practise code review by a fellow senior. If someone leaves or is off for an extended period, the second senior is already active in the codebase and can take over after a short handover. You are therefore never left at a standstill. For longer engagements, we run a more formal knowledge transfer session in which the successor is brought up to speed without your own team having to do it.
How is knowledge transferred at the end of an engagement?
A standard part of every engagement: a runbook with operational instructions, an architecture document explaining the non-trivial decisions (why a server component here, why a client component there, which rendering strategy per route), Storybook stories for components where appropriate, and walkthrough sessions with your own team or successor. Preferably held in the final sprints of the engagement, not on the very last day of the collaboration.
How is pricing determined?
For team augmentation and dedicated developers we charge an hourly rate based on seniority (mid-level, senior, lead). For project-based scopes we charge per sprint or a fixed total budget based on a scope document. We share rates openly in the introductory conversation: no hidden tiers, no penalty clauses and no surprises halfway through.
Do you also do full-stack work, or front-end only?
Both. Many of our Next.js developers work full-stack: server actions, API routes and data access via Prisma sit in the same codebase as the UI. For heavier backend requirements, such as a separate Python API for ML, a Node.js microservice for pricing or a Go service for high throughput, we combine the work with a
full-stack developer or a dedicated backend developer.
Who owns the code?
You do. The code is written in your Git repository under your account. The intellectual property rights to everything built under commission belong to you, contractually agreed. Any open-source libraries we use are clearly documented, including their licences, so that your own team or an audit can easily check them later.
