Next.js collects build times, feature usage, and error events from developer machines during builds, and the data goes to Vercel. It is opt-out, not opt-in. Stopping it requires setting NEXT_TELEMETRY_DISABLED=1 or running next telemetry disable. Teams that adopted Next.js before the telemetry was introduced shipped it on by default without knowing.
The assumption embedded in the stack
The feature exists because it is useful to Vercel, and the default is opt-out because opt-in would produce less data. Nothing about this is unusual: it is the standard model. Most modern frameworks assume a central collector exists.
Many logging libraries default to cloud log aggregation endpoints. Many error-tracking clients phone home to Sentry, Datadog, or similar on import. The analytics client loads and initialises in the same bundle as your application code. The telemetry is not always in your code. It is in your dependencies, your build tooling, and your framework's default configuration.
This matters because you can disable a feature flag you know about. You cannot disable the one you have not found yet. A network trace during development builds, not just a reading of the documentation, tells you what your software is actually calling.
What "no telemetry" usually means
Most software that claims no telemetry has turned a feature flag from on to off. The claim rests on a terms-of-service clause that says "we don't sell your data," a config file with telemetry: false, a privacy policy with carefully worded language about what counts as telemetry versus essential service data versus aggregate analytics, or a blog post announcing that tracking has been removed.
None of these is the same as a system that cannot collect. Turning a flag off is a policy decision, not an architectural one. The policy restrains behaviour; it does not remove capability. The flag can be turned back on when the terms of service change, when the company raises a new round, or when a dependency ships a new default.
The privacy guarantee in this model is as durable as the organisation's current incentives, which is a weaker guarantee than most users assume they are getting. Genuinely telemetry-free software is structurally different: there is no collection path to enable, because the architecture never built one.
What it means architecturally
Genuine privacy comes from data that never exists, not data that is deleted or not retained. If the architecture supports collection and you have chosen not to collect, that choice is revocable. The design questions that reveal which kind of system you are building:
- Where would the data go if you wanted to collect it? Is there a network path from the client to a collector you control?
- Is there a central account or user identifier that aggregation would require?
- Is there a schema, even an informal one, for the data you might want to collect?
- Are there third-party SDKs loaded in the client that have their own collection logic independent of yours?
If all answers point to nothing, the architecture supports the claim. If any answer is "here, but we chose not to use it," the architecture does not. The choice can be reversed; the architecture cannot be reversed by reading the privacy policy.
| Property | Policy off (a setting) | Architecturally absent |
|---|---|---|
| Collection path | exists, currently unused | was never built |
| To re-enable | flip a flag, change a default | ship new code and infrastructure |
| Who can reverse it | a future product decision | nobody, without a redesign |
| What proves it | a privacy policy you must trust | a network trace showing nothing leaves |
| Durability | as long as incentives hold | structural |
Local observability
Removing the telemetry pipeline creates a real engineering problem: how do you know when something is broken? Error rates, performance regressions, and usage patterns are what telemetry answers. Removing the pipeline does not make the questions go away. Three patterns address this without reintroducing collection:
Structured local logs. Errors and events write to a local file the user can inspect. If the user wants to report a bug, they share the log file with an explicit copy-paste or upload. Nothing leaves the machine automatically. This is weaker for aggregate trend analysis and stronger for the user's ability to understand what the software is doing.
Opt-in crash reports. A crash writes a report to a local file and presents the user with the contents before asking whether to send it. The user reads the report, decides it is not sensitive, and clicks send. This is how macOS and many desktop applications handle crash reporting. It requires more friction than background transmission, which is the point.
Synthetic monitoring from your own infrastructure. Rather than embedding monitoring in the client, run external probes that exercise the service from infrastructure you control. The monitoring is on your side of the network boundary, not the user's. Usage pattern analysis happens through server-side logs of requests you receive, not through client-side tracking of what users do between requests.
The strongest privacy guarantee is not "we don't retain your data." It's "the data was never transmitted."
The framework problem
Build tooling telemetry is the category that most developers discover last. Next.js is the most visible example, but the pattern is broad: Angular CLI, various bundler plugins, language version managers, and many developer experience tools collect usage data from developer machines. The data collection is disclosed; it is rarely prominent.
For a production service, the framework telemetry runs on developer machines, not production servers, so users are not directly exposed. For a software distribution, if you ship the build tooling or developer environment to users, the framework's own telemetry is in scope and must be accounted for. Verifying that all opt-outs are in effect requires a network trace during a build or development session, not just confirming that the environment variable is set.
A practical audit
Run a network trace during a fresh install of your software. Count the outbound connections to third-party hosts that are not user-initiated. Each one is a telemetry or dependency endpoint you may not have inventoried. For each: is it necessary for the software to function? Can it be replaced with something that does not call out? If neither, has the user been told, and do they have a real option to decline? Software that claims no telemetry should have done this audit and be able to answer these questions.
The minimal data principle
Data minimisation is a design constraint applied at the schema level before any collection decision is made. The question is not "should we collect this?" but "what is the minimum information the system needs to function?" Each datum that never enters the system cannot be stolen, subpoenaed, or accidentally exposed.
Practical applications of this in architecture: no user accounts where anonymous access would serve the purpose; no email addresses where a hash or token would work; no persistent identifiers where a session identifier would do; no full request logging where summary statistics answer the operational questions.
The discipline is harder than it sounds. Teams add identifiers for convenience, keep fields they stopped using, and log more than they need because storage is cheap. The data accumulates without active decisions to accumulate it. Minimisation requires active decisions not to accumulate it, which run against the grain of most engineering cultures.
What would you add, or push back on? Tell me on X.