Lesson 72 of 81

Experimental Features and next.config

Q: A teammate wants to adopt a Next.js feature that's currently behind an experimental flag in next.config. How would you evaluate whether to take that on, and what real risk are you accepting?

A strong answer covers: Understands experimental flags sit outside Next.js's normal stability/breaking-change guarantees — config shape or behavior can change or be removed in a minor version; Distinguishes 'unstable API contract' from 'buggy' — many experimental features work fine in practice, the risk is the promise about the future shape; Names a concrete mitigation: pinning the Next.js version, reading release notes before upgrading, checking real-world adoption reports.

New Next.js capabilities often ship years before they're the default — gated behind an experimental flag in next.config so you can opt in early, with no promise the API stays the same by the time it stabilizes.

11 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

No quiz for this one — it's a practical topic

This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.

Be interviewed on this →

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Experimental Features and next.config

What interviewers actually ask about this, and what a strong answer has to cover.

A teammate wants to adopt a Next.js feature that's currently behind an experimental flag in next.config. How would you evaluate whether to take that on, and what real risk are you accepting?

A strong answer covers

Understands experimental flags sit outside Next.js's normal stability/breaking-change guarantees — config shape or behavior can change or be removed in a minor version
Distinguishes 'unstable API contract' from 'buggy' — many experimental features work fine in practice, the risk is the promise about the future shape
Names a concrete mitigation: pinning the Next.js version, reading release notes before upgrading, checking real-world adoption reports

Likely follow-ups

If a minor version bump removes the flag you depend on, is that a Next.js bug you'd file, or expected behavior?
How would you decide whether a given experimental feature is safe enough to ship to production versus too risky?
Does turning on an experimental flag in next.config always apply project-wide, or can it be scoped more narrowly?

Practice these with the AI interviewer →

The plain-language idea

Next.js doesn't wait until a feature is fully finished to let people try it. New capabilities routinely land first behind an experimental block in next.config.ts (or .js) — off by default, opt-in only, clearly labeled as unstable. This lets the team gather real-world feedback before committing to a final API shape, and lets you use something genuinely useful months or years before it graduates to stable.

The tradeoff is explicit: an experimental flag can change its config shape, change its runtime behavior, or disappear entirely between minor versions — none of which counts as a breaking change in Next.js's own versioning, because experimental features are explicitly outside the stability guarantee. You're trading stability for capability, on purpose, for a specific opt-in surface.

See it in a real thing: turning one on

// next.config.ts
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  experimental: {
    // Each key here is one specific experimental feature, off by default.
    // Check the Next.js release notes for what's currently available —
    // this object's contents change across versions.
    ppr: "incremental",
  },
};

export default nextConfig;

Turning on an experimental flag is a project-wide decision, not a per-route one (with the partial exception of features like ppr: "incremental", which lets you then opt individual routes in with a experimental_ppr route export — the flag unlocks the capability, a separate per-route setting controls where it's actually used). Read the release notes for the version you're on before flipping any of these — the same flag name can mean a different thing, or expect a different value, a few minor versions apart.

What people usually miss

Watch out

"Experimental" doesn't mean "buggy" — it means "the contract isn't final." Plenty of experimental features are solid in practice; what's actually unstable is the promise about how they'll look going forward, not necessarily their correctness today.
An experimental flag disappearing on upgrade isn't a bug report, it's expected. If a minor version bump removes or renames an experimental config key, that's within Next.js's stated guarantees — pin your Next.js version deliberately if you're relying on one, and read the release notes before every upgrade.
Not every experimental feature graduates. Some are removed outright after feedback shows a better direction. Adopting one is a bet on the idea, not a guarantee the exact API you're using today survives to stable.

The genealogy: the same feature-flag idea you'd build yourself, run by the framework

This is conceptually the same thing as a feature flag you'd roll out in your own app — ship a capability dark, let a subset of usage opt in, watch how it holds up, then make it the default once it's proven. Next.js just runs that process at the framework level, with next.config's experimental block as the flag and a stable release as the eventual default-on moment.