Most software that claims no telemetry has turned a feature flag from on to off. That is a policy decision, not an architectural one. 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. Genuinely telemetry-free software is structurally different: there is no collection path to enable, because the architecture never built one.
The assumption embedded in the stack
Most modern frameworks assume a central collector exists. Next.js collects build telemetry by default and requires NEXT_TELEMETRY_DISABLED=1 to stop it. 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
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. A blog post announcing that tracking has been removed.
None of these are the same as a system that cannot collect. The policy restrains behaviour; it does not remove capability. A future decision, a business pressure, or a dependency update can restore the collection path. 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.
The Next.js case
Next.js telemetry collects build times, feature usage, and error events from developer machines during builds. It is opt-out, not opt-in. The data goes to Vercel. Disabling it requires setting an environment variable or running next telemetry disable. Teams that adopted Next.js before the telemetry was introduced shipped it on by default without knowing. The feature exists because it is useful to Vercel; the default is opt-out because opt-in would produce less data. This is not unusual. It is the standard model.
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.
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 to not accumulate it, which run against the grain of most engineering cultures.
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?
The goal is not perfection. It is honesty: software that claims no telemetry should have done the audit, be able to answer these questions, and have an architecture where the answer to "where would the data go?" is genuinely "nowhere, because there is nowhere to go."
Most software that says "no telemetry" has flipped a flag from on to off. That is a policy, not an architecture. The flag can come back when the terms change, when a new round closes, or when a dependency ships a new default. Telemetry-free software is different in kind: there is no collection path to switch on, because the code to collect was never written.
The pipe is mostly not yours. Modern frameworks assume a central collector. Next.js collects build telemetry by default and needs NEXT_TELEMETRY_DISABLED=1 to stop. Logging libraries default to cloud endpoints, error clients phone home on import, and SDKs initialise before your code runs. You can disable a flag you know about; you cannot disable the one you have not found. A network trace during a build, not the README, tells you what your software actually calls.
A policy restrains, it does not remove. A clause that says "we don't sell your data," a config with telemetry: false, a blog post announcing removal: none of these is a system that cannot collect. The capability stays. A future decision, a business pressure, or a dependency update can restore the path.
The strongest guarantee is not "we don't retain your data." It is "the data was never transmitted."
The architectural test
Ask where the data would go if you wanted it. If the answers all point to nothing, the claim holds. If any answer is "here, but we chose not to," it does not.
- Is there a network path from the client to a collector you control?
- Is there a central account or identifier that aggregation would need?
- Is there a schema, even informal, for what you might collect?
- Are there third-party SDKs with their own collection logic?
Observability without a pipe
Killing the pipeline does not kill the questions: error rates, regressions, usage. Three patterns answer them without collecting.
- Structured local logs: events write to a file the user can read and share by hand. Nothing leaves automatically.
- Opt-in crash reports: show the user the report, then ask before sending. The friction is the point.
- Synthetic monitoring: probe the service from infrastructure you control, on your side of the network boundary, not the user's.
Minimise at the schema
Data minimisation is a design constraint set before any collection decision. Not "should we collect this?" but "what is the minimum the system needs?" No accounts where anonymous works, no email where a token works, no full request logs where summary stats answer the question. Each datum that never enters cannot be stolen, subpoenaed, or leaked.
The discipline is harder than it sounds: teams add identifiers for convenience and log more than they need because storage is cheap, so the data accumulates with no decision to accumulate it.
Run a network trace on a fresh install and count outbound connections you did not initiate. Each is an endpoint you may not have inventoried. The goal is not perfection, it is honesty: be able to answer "where would the data go?" with "nowhere, because there is nowhere to go."