An independent effort, near-zero cost, no data broker

Every product is a machine on the other side of a transaction. The useful question is not what it costs. It is what that machine wants from you.

Cloud products usually want your data. Three business models come up again and again. Sell the data. Sell attention to advertisers. Or use your activity as free training. Those models exist because the usual math forces them. Storing and processing one person's data costs the maker real money, and someone has to pay that bill.

This product's answer is that the bill mostly does not exist. Analysis runs on your device. The default deployment has no server at all. The optional account layer fits inside basic free tiers. The things a broker would need — collected data, a sales channel, an incentive — are each absent by structure, not by promise.

This post lays out the costs, so the ethics can be checked rather than asserted.

1. 2minthe cost inversion: whose CPU, whose bill.
2. 5minwhere the bill actually goes, and the three absences that kill the broker model.
3. 10minwhat "near-zero" honestly hides, and how to verify it.

The cost curve that makes the rest possible

Most cloud software has one hard fact: every user's data passes through the maker's servers and is worked on by the maker's computers. At one user that is pennies. At a million users it is a data centre. When costs grow with the user count, the need to earn from each user grows too. That is where "the user is the product" stops being a slogan and becomes a bill to pay.

An independent effort sidesteps that pressure by running the work where the data already is. Your archive is unzipped, parsed, indexed, compared and queried on your own machine. The analysis engine makes zero network calls on purpose for that work.¹ So the maker's cost per user is not compute, storage and bandwidth for your archive. It is serving a static app bundle — roughly the same bytes for the millionth user as for the first. Storage scales on your device. In the default mode, the archive never moves across the maker's servers.

This is not charity. It is the architecture paying its own way. It is also the precondition that makes "no data broker" structurally plausible, rather than relying only on good intentions. A product that never receives your data simply does not have the dataset that a broker would need to collect in the first place.

What the bill actually looks like

The optional account layer is the only part that costs anything to run. Its bill is small and predictable: a static app plus a small optional server surface on free hosting and database tiers. It also adds free object storage for the encrypted profile packs, and a transactional-email provider that stays dormant until an account is created.²

Nothing in that list scales with how much archive data you bring, because the archive never reaches the server. The account and sync tier was designed backwards from free-tier limits: one small encrypted pack per person, and no media at all. That is as much a money decision as a security one.

With the account layer unconfigured (the default), there is no server bill beyond hosting a static app — effectively the costs of a static site. Note what is not on the bill: no media-delivery charges (because none is stored), no per-row storage for archives (because none is received), no inference compute (because no model runs), and no data pipeline to enrich anything (because nothing is collected). Each missing line item is something another product pays for precisely because it holds your data.

The honest tradeoff: those free tiers are not promised forever. Providers can change limits, quotas or rules over time. The mitigations are straightforward — keep the stored payload lean, avoid collecting data that would bloat costs, and preserve a zero-server default that works regardless of hosting changes. Near-zero cost is a structural posture, not a permanent price guarantee.

Why the broker model does not fit

A data broker needs three things. Here is each one, checked against this product's structure.

1. Data worth selling. In the default mode, the maker never receives your archive. There is no upload path, so the dataset that would be sold does not exist on the maker's side of the wire.² In the opt-in modes, the maker holds only what is necessary to run the opted-in feature: an encrypted email address, credential hashes, session hashes, and, only if you enable sync, a lean encrypted pack of your own totals.³ There is no media, no raw messages without a separate opt-in, and no other person's data, ever. This is closer to a password manager's minimal holdings than a social platform's.

2. A channel to sell it through. The refusals list documents the absence: no advertising SDKs, no affiliate links, no marketing scripts, no behavioural tracking. One redacted page-view counter is the entire outbound telemetry.⁴ Without a buyer-side integration or ad inventory, there is nothing to connect a dataset to a buyer.

3. An incentive — revenue machine aimed at user data. There is none. No growth target depends on engagement. No ad auction improves with more data. And the license is noncommercial: use, audit and running are permitted, while selling the software or derivative services is not.⁵ That same license constrains anyone who forks the idea, so the refusal travels with the source. This is an intentional limit for a small project with no investor pressure.

On retention, the posture points the same way. Erase is instant: the profile goes at once, the account is hard-deleted after a 30-day grace, and local data clears with a single tap. A broker's core asset — retained history — is actively destroyed on request rather than quietly archived.⁶

The conclusion is simple by design: selling data would require having it, reaching buyers, and wanting to. All three fail as engineering facts, not as moral resolutions. That is the only durable kind of "we would never".

What "near-zero" is honestly hiding

The title says near-zero, not zero. The difference is where the honesty lives. For a small independent effort, the tradeoffs need to be stated plainly.

• Free tiers change. A hosting, database or storage provider can raise its limits or prices. Free-tier headroom is a snapshot, not a contract. The mitigations are lean storage, deliberate provider choices and, most importantly, a default mode that costs nothing regardless of what hosting does.
• The real cost is time. Building and maintaining the product is the actual budget line, not servers. That cuts both ways: it keeps costs low, but it also means support, reviews, fixes and feature work are limited by human time. A small project cannot match the support hours of a larger team.
• No corporate machine — which has downsides. There is no funding round to service, no board pushing growth, and no acquisition pressure that would value the user base for its data. That removes the strongest incentives to broker data. It also means no uptime promise, no 24/7 incident response, and no dedicated support channel beyond what time allows.
• Fixed costs still exist. The domain and platform accounts are real money that fits in a personal budget. "Near-zero" describes the shape: costs are fixed rather than per-user. Per-user cost is what forces per-user monetisation, and that is the line this architecture deletes.
• Longevity is not promised. A small project can pause or wind down. That is an honest tradeoff: you get a local-first tool with minimal data exposure, but you do not get the permanence of a well-funded commercial product. The local-first default helps here — even if the hosted tier changes, your analysis still runs on your own device with the data you already have.

The inversion compounds. An archive that never crosses a server cannot be breached on one, subpoenaed from one, or mined in one. The cost saving and the custody guarantee are the same fact seen from two sides. The tradeoff is scope and time, not privacy.

Questions this comes up

The security post covers custody, encryption and erase in detail. The local-first post covers the network-off check. The refusals post lists the features that would have been a broker's toolkit. The off-by-default post covers exactly what enabling the optional layer creates.