Skip to content
fullstack.sg
Menu

Framework and architecture

Next.js applicationsbuilt to stay fastand up to date

Who it’s for
Teams starting a new Next.js build, Teams on an older version, Agencies whose sites became applications
To start, send
The existing repository, if there is one
Pricing
Quoted for each project

New Next.js builds, upgrades and rescues, with each page set up to render, cache and deploy the right way.

Discuss a projectHow pricing worksOne-pager for your proposal
  1. Interface (used by this service)
  2. Logic (not central to this service)
  3. Data (not central to this service)
  4. Integrations (not central to this service)
  5. Deployment (used by this service)

Is this for you?

With Next.js, each page can be built ahead of time, rebuilt when content changes, rendered on the server for every visit, or run in the browser. Those choices decide how fast the site is, what hosting costs, what search engines see, and how quickly an edit goes live. Our frontend service covers the interface itself; this one covers how the application around it is put together.

For new builds we use the App Router. The decisions that matter most are which parts run on the server, which pages are cached and for how long, and where calls to other services happen. Get them right and the site is fast and cheap to run. Get them wrong and it feels fine on a laptop but turns slow, expensive or out of date once it’s live.

Who it’s for

  • Teams starting a new Next.js build

    You want the routing, rendering, data and deployment set up properly from the start.

  • Teams on an older version

    Your application is on the Pages Router or an older major version, and it isn’t clear how to upgrade it.

  • Agencies whose sites became applications

    A marketing site now has logged-in areas, personalisation or integrations, and the original setup is struggling.

Usually, one of these has just happened

  • Pages are slow, or content changes take ages to appear, or appear on some pages and not others.
  • Hosting costs have grown faster than traffic.
  • Search engines can’t see content that only appears once the browser runs JavaScript.
  • A major upgrade keeps getting postponed because nobody’s sure what it will break.

Every route, rendered on purpose

The biggest Next.js decision is when each page gets rendered. Here’s how we’d set up a typical agency-built site, giving each page the cheapest option that keeps its content correct.

Illustrative route map
Example routes and their rendering mode
RouteStaticBuilt onceRevalidatedRebuilt on changeDynamicPer requestClientIn the browserWhy
/HomepageStaticOnly changes when the content does, so it’s built once and served from a CDN.
/services/[slug]Service pagesStaticGenerated for each service at build time.
/journal/[slug]CMS articlesRevalidatedRebuilt when an editor publishes, triggered by the CMS.
/productsProduct listingRevalidatedRefreshed every few minutes, because stock levels come from another system.
/searchSearch resultsDynamicDifferent for every search, so it’s rendered on the server each time.
/accountSigned-in areaDynamicShows personal data, so it’s rendered for each visit and never cached publicly.
/account → mapInteractive map widgetClientOnly the map runs in the browser. The rest of the page comes from the server.

What you get

  1. A rendering plan per route

    Which pages are built ahead of time, which refresh when content changes, and which render on every visit, written down so new pages follow the same rules.

  2. Application structure

    Routes, layouts and shared components, with code that handles secrets or the database kept on the server and away from the browser.

  3. Data fetching and caching

    Calls to your CMS and other services made from the server, and cached until the content actually changes.

  4. Technical SEO foundations

    Content in the HTML search engines receive, plus page titles, canonical URLs, sitemaps and structured data generated from the same content as the pages.

  5. A deployment setup

    Separate settings for development, preview and production, and, where your hosting supports it, a preview link for each change and a way to roll back a release.

Before we start

What we’ll need from you

The existing repository, if there is one
The version, router, packages and hosting decide where we start.
Where the content comes from
A CMS, a database, files or another company’s API each suit different approaches.
How often content changes
Prices that change hourly and a policy page that changes yearly shouldn’t be handled the same way.
Where it has to be hosted
Vercel, another platform or your own cloud account changes which features are available.
Your traffic and audience
How many visitors you get, and where they are, affects caching and cost.

Decisions we’ll help you make

Vercel or self-hosted?

Vercel supports every Next.js feature with the least setup. Hosting it yourself in a container works, and is sometimes required, but some features then need extra configuration. We’ll recommend whichever fits your situation.

How much JavaScript in the browser?

As little as the page needs. We render on the server by default and only send JavaScript for the parts people interact with. That makes pages faster on real phones, and it’s much easier to keep it low from the start than to cut it down later.

Upgrade incrementally or rebuild?

The old and new routers can run side by side, so most upgrades can happen one route at a time. A rebuild only makes sense if the application needs restructuring anyway.

When is Next.js the wrong choice?

For a simple brochure site that non-developers update, a hosted website builder may be cheaper to run and easier to change. We’ll tell you if that’s the case.

How the work runs

  1. 1

    Review

    We read the code or the brief and list where content comes from and how often it changes.

  2. 2

    Plan

    A short written plan covering the routes, rendering, data and deployment.

  3. 3

    Foundations

    Project setup, layouts, metadata, environments and automated checks.

  4. 4

    Build or migrate

    One route at a time, so each can be checked on its own.

  5. 5

    Measure

    We check speed and caching on a setup that matches production.

  6. 6

    Hand over

    Notes on how to add routes and content without undoing the structure.

Usually included

  • New Next.js applications and sites
  • Upgrades between major versions, including Pages Router to App Router
  • Decisions on rendering, caching and data fetching
  • Technical SEO implementation
  • Deployment setup on Vercel or in containers

Not included unless agreed

  • Content strategy and keyword research
  • Managing your hosting account billing
  • Promises about search rankings

Next.js changes often, and hosting platforms differ in what they support. Your CMS or other services may also limit how often we can fetch from them or how long we can cache.

The full process, from first message to handover, is on How we work.

How the costis worked out

Next.js work ranges from a short review to a full build. For an existing project, we usually suggest starting with the review, because it gives us something solid to estimate the rest from.

After a first call, we send a written quote that says what’s included and what isn’t.

What affects the cost

  1. Whether it’s a new build, an upgrade or a migration
  2. How many page types and content sources there are
  3. Sign-in and personalised content
  4. Other services the pages depend on
  5. Where it’s hosted, and what that host allows
  6. The size and condition of the existing code

Questions

How is this different from your frontend development service?

Frontend development covers the interface: components, responsive layouts and accessibility, in whatever framework you use. This service covers how the Next.js application around it works: rendering, routing, data, caching and deployment. Plenty of projects need both.

Can you upgrade our Next.js app to the current version?

Usually, yes. We’d run the official upgrade tools, check which of your packages are affected by the changes, and do the upgrade on a separate branch so it can be tested before anything goes live.

Will Next.js make our site rank better?

Not on its own. It makes it easy to serve fast pages with the right metadata, which removes technical problems, but rankings depend on much more than that.

Do we have to host on Vercel?

No. It’s the simplest option, but Next.js also runs on other platforms and in containers. We’ll explain what changes if you host elsewhere.

Starting, upgrading or untangling a Next.js project?Discuss a project →Send us a link to the code, or tell us what you’re planning. We’ll say whether a short review is the right place to start.