trackselfprivate time infrastructure

Blog

The Quiet Second Business Model: Selling User Data

Janez Štupar · 24.4.2026

I still remember the excitement of the product manager when she came to the development team with a new monetization strategy. She was convinced she had found a gold mine. The company ran a two-sided marketplace in real estate. Users had given us personal information because they needed the service to work. Internally, that same data was now being discussed as something insurance companies might pay for. Nobody in the room treated it like a scandal. That was the part that stayed with me.

We have all heard the public version of this story by now: companies collect data about us, other companies buy it, and data brokers package our lives into categories, scores, and lists. There are mainstream articles about data brokers, opt-out services, browser extensions, privacy guides, and regulator-mandated unsubscribe forms. There are also long lists of companies most people have never heard of that may still have a profile about them.

That version is bad enough. It is also not the part that bothers me most. What gets less attention is what happens before the data reaches a broker: a normal software company looks at its database and realizes someone else might pay for it. The users came for the marketplace. Behind their backs, the company found a second customer for their data. That is the part people underestimate.

The data broker story is already public

And to be clear, the broker side is not a minor problem. In January 2024, the FTC announced an order against X-Mode Social and Outlogic, saying the companies sold precise location data that could reveal visits to medical and reproductive health clinics, places of worship, and domestic abuse shelters. The FTC said the raw location data was tied to mobile advertising IDs and was not anonymized. That same month, the FTC announced an order against InMarket, a company that collected location data from its own apps and from third-party apps using its SDK. The FTC said InMarket had nearly 2,000 audience segments, including categories such as parents of preschoolers, Christian church goers, and wealthy and not healthy. The complaint also said users were told location data would support app functions like shopping rewards or shopping lists, while the data was also combined with other information for targeted advertising. In December 2024, the FTC took action against Mobilewalla. The agency alleged that Mobilewalla collected more than 500 million unique advertising identifiers paired with precise location data, including data from real-time bidding exchanges. The FTC said the company used location data from women who visited pregnancy centers to build audience segments targeting pregnant women, and used audience data to analyze people who attended protests after the killing of George Floyd.

This is not abstract "marketing data." It can reveal where people worship, where they seek medical care, where they protest, where they work, and where they sleep. The CFPB has also proposed treating some data brokers more like credit bureaus under the Fair Credit Reporting Act, arguing that brokers sell sensitive personal and financial information that can be used for scams, stalking, spying, and surveillance. So yes, the visible data broker industry matters and should be checked. But it is only part of the problem.

The problem is bigger than data brokers

The phrase "data broker" makes the problem feel separate from normal software. It is easy to imagine data brokers as a separate category of a company, somewhere downstream from the apps you actually use. The reality is that any software company with enough users, enough behavioral history, or enough sensitive workflow data can be tempted to become a data business.

A marketplace knows who needs what, when, and why. A time tracking system can know which clients are active, which projects are under pressure, where a team is spending its attention, and which relationships are starting to consume more time than expected. Some of this data can be obviously personal or commercially sensitive. Some of it looks harmless on its own. The trouble starts when it gets matched with everything else. This is where the money is.

The old line is: if you are not paying for the product, you are the product. That was always incomplete. Often, even when you are paying, the vendor is still looking for a way to double dip. Subscription revenue from users on one side. Data revenue from buyers on the other. The user thinks they are using a product. Internally, the same relationship can start to look like an inventory problem: what do we have, who would buy it, and how can we package it?

The standard defense is that users consented. Sometimes that is formally true. A privacy policy may contain language broad enough to permit sharing, licensing, analysis, "partners," "affiliates," "business purposes," or "de-identified" data. But consent buried in legal text does not mean the user understood the economic bargain.

Nobody signs up for a productivity tool, a marketplace, or a scheduling app thinking: "I am also authorizing this company to discover which outside industries might pay for behavioral inferences about me." And even when data is described as aggregated or de-identified, the risk does not disappear. Location traces, behavioral patterns, timestamps, workplace context, and rare combinations of attributes can make people or companies identifiable again, especially when matched against other datasets. A better test is architectural: can the vendor exploit the data if the incentive appears?

Why I care about architecture

Privacy promises are cheap when the vendor can read everything. A company can say it respects privacy, that it does not sell data, and that it only uses data to improve the service. It can also change the policy later, or avoid saying that part loudly. But if the service is built so the vendor has routine access to raw customer data, the business temptation remains. A future executive team can change the policy. A desperate quarter can change priorities. An acquisition can change incentives. A new partnership can make previously ignored data look valuable.

The stronger position is different: design the system so the vendor cannot casually monetize what users put into it. That does not solve every privacy problem. Metadata still matters. Billing records still exist. Support workflows still need care. But there is a meaningful difference between a vendor promising not to exploit readable customer data and a vendor building around the assumption that customer data should not be vendor-readable in the first place. This was one of the reasons I started working on Trackself. Time tracking looks mundane until you understand what it contains. For individuals, it can expose routines, productivity patterns, working hours, health-related absences, side projects, and personal habits. For teams, it can expose clients, matters, projects, internal priorities, delivery pressure, profitability, and staffing decisions. For legal, healthcare, security, finance, defense, and other sensitive work, time data is not just admin data. It is operational context. I do not want a time tracking vendor to be another company sitting on readable records of that context. That experience changed how I think about building software. With Trackself, I do not want customer time records sitting there, readable, waiting for someone to invent a secondary use.

The honest privacy standard

The honest standard is not "trust us." For me, the standard is simple: collect less, retain less, and make sensitive data unreadable wherever the product allows it. Do not build a business model that depends on secondary data sales. If control matters, give customers deployment options. Most importantly, make the architecture match the promise. Opt-out services may help around the edges. Regulation may close some of the worst gaps. Enforcement actions matter.

But the deeper fix is product-level. Software companies should not treat user data as a reserve asset waiting for the right buyer. Users should be more skeptical of any tool that asks for sensitive data, stores it in readable form, and then says the only protection is a paragraph in a privacy policy. I still remember that product manager's excitement. I would rather build software where that kind of pitch is harder to make in the first place.

Sources

Janez Štupar
24.4.2026