Why I Built a Subscription Tracker With No Account: A Privacy Decision Tree

1. The threat model most people don't think about

When someone searches "best subscription tracker," they're usually comparing UI, free vs paid, and whether it does cancellation reminders. They are almost never asking: where does my data physically live, who can be compelled to hand it over, and what does the company do with the most intimate financial record I'll ever keep on a phone?

A subscription list answers questions that are otherwise private: what streaming services you use, which gyms you belong to, which dating apps, which health services, whether you pay for a VPN or a recovery program or a content subscription you'd rather not explain. The list is also a target for resale - lenders, advertisers, debt buyers, and data brokers all pay for inferred financial profiles, and "active subscriptions" is one of the highest-signal fields.

There are two ways to respond to that: tighten security around the data you collect, or stop collecting it. I picked the second.

2. The decision tree I used

For each design question, I asked: can the user be harmed by the data this feature creates? If yes, the default is "do not collect it."

• Email signup at install? Skip. Replace with an optional, local-only nickname.
• Cloud sync so users don't lose data across phones? Skip. Replace with encrypted local backups the user controls (JSON export to anywhere they want).
• Anonymous usage analytics to improve the app? Skip. Replace with opt-in feedback and a public changelog.
• Push notifications for renewal warnings? Allowed, scheduled locally with the OS scheduler. No remote trigger.
• "Insights" features that require aggregating users? Skipped entirely. They would have required a server.
• Cancel-flow scripts bundled in the APK? Allowed, versioned in-app, verified manually, no remote fetch.

Notice the pattern: features that create the most sensitive data get the most isolation, and features that improve convenience get the most transparency about what they're doing.

3. What "encrypted local" actually means in code

The data sits in a SQLite database on the phone (Drift, which is the same SQLite you know, just with type-safe Dart bindings). The database file is stored in the app's private directory, which is inaccessible to other apps on stock Android. Backups are written to a user-chosen location as JSON, optionally password-protected with a per-backup random key.

The codebase does not contain any code that transmits subscription entries, prices, notes, or cancel-flow usage to a server. The Android internet permission is not declared in the manifest for the core feature set. If you want to verify this, the Play Store APK is reproducible from the public source.

Cancel Coach scripts - the 77+ services worth of step-by-step cancellation instructions - ship inside the APK as a versioned JSON asset. When the data goes stale, the user gets an in-app update notice, not a silent network refresh. I would rather show "this flow is 4 months old, double-check the URL" than quietly phone home.

4. The things this costs us (and you)

No cloud sync means if you lose your phone and have not exported a backup, your data is gone. That is a real cost. I would rather lose users to that than put their subscription list on a server.

No analytics means we don't know which screens confuse people, where they abandon onboarding, which categories of subscriptions are tracked most, or which cancel flows fail. We learn from support emails and from the very kind of feedback you can leave on the Play Store.

No "smart" features means we can't auto-detect subscriptions from your email or bank statement. We can't tell you "you spent 12% more this month" by aggregating across users. We can only show you what you told us, on the device you told us on.

These are real product tradeoffs. They are the price of the privacy stance. I want you to see them, not just the marketing.

5. How to check whether any finance app deserves your data

A short checklist that applies to dropsub and to anything else you might try:

1. Open the app's privacy policy. Search for "share," "partners," and "advertisers."
2. Look at the Android app permissions with a tool like Exodus Privacy. Any "Internet" + "Read phone state" combo is a flag, especially for an app that has no business phoning home.
3. Disconnect from Wi-Fi and use the app. If features break, the app is phoning home.
4. Read the company's funding. Free apps paid for by advertisers or VCs expecting a liquidity event collect your data; that is the business model. A one-time purchase is a much better signal.
5. Ask whether the company has ever been subpoenaed, and how they responded. The answer tells you what your day in court would look like.
6. Check the manifest. A finance or subscription app that does not declare analytics SDKs is rarer than it should be.

6. The deeper point: a free subscription app is a paradox

The reason a paid subscription tracker costs $4.99 and a "free" one is "free" is that the free one has to monetize somewhere. The cheapest monetization for a finance-adjacent app is data resale. The second cheapest is "premium" upsells after you have already entered a year's worth of subscriptions, which is its own form of lock-in.

I picked the one-time $4.99 model specifically because it aligns the incentives. You pay once. I get paid. Neither of us has a reason to keep an ongoing data relationship alive. If you hate the app, you can stop using it tomorrow and we have no way to follow up, because we never had your email.

That is the whole pitch: a private, local, no-account subscription tracker that is also structurally incapable of becoming the next data-resale story.

7. Try it, and tell me what I missed

dropsub is available on Google Play for a one-time $4.99. If you find a place where the privacy stance created a worse experience than necessary, I want to hear about it. The whole point of this project is to be useful and private, and "private but annoying" is a failure mode I am actively working on.

If you read this far, you are the audience I built this for. Thank you.