Why did we build another GLP‑1 tracker?

Why privacy matters

Health data is among the information people have the strongest reason to keep private. Using it to sell someone a product or choose the ads they see is not a harmless technical detail. It reaches into a person’s freedom to make choices without being watched.

A GLP‑1 record is more revealing than a handful of numbers. Dose dates and changes, side effects, weight trends, nutrition, and personal notes can grow into a detailed health history—often a more intimate one than the user first realizes.

So we did not begin by asking how to collect that history and protect it. We asked a simpler question: does Mounjari need to collect it at all? The answer was no. The app can record, remind, chart, and export without Mounjari owning a copy of your health history.

The strongest protection is data we never receive

A company can promise not to sell your data. It can encrypt it and limit who may open it. All of that matters, but it happens after the data has been collected. Mounjari starts one step earlier: your doses, symptoms, weight, nutrition, and notes stay on your device or, if you enable Apple sync, in your personal iCloud account. Mounjari does not receive them or send them to product analytics.

A database we never built cannot be browsed by an employee, exposed in a breach of our servers, inherited by a buyer, or repurposed by new management. That is not a slogan added to the website. It is a choice in the structure of the product.

It is also the plain meaning of data minimisation under Saudi Arabia’s Personal Data Protection Law: collect only what the product needs. Mounjari works without a central health record, so we have no reason to ask you for one.

How the six apps differ

I compared what each company publishes, not what I would like to be true. Mounjari keeps its health history outside a company account and sends no health entry to product analytics—no dose amount, symptom, weight, nutrition, or note. On iOS, RevenueCat records each subscription-screen impression and an internal ID that can identify its context, such as onboarding, dose, weight, or a follow-up offer; it does not receive the health entry itself. WiserApps also says its GLP‑1 Tracker keeps health data on the device and needs no account, but its App Store label declares usage and diagnostic analytics, while its linked policy describes much broader collection and advertising practices.

Removing a name does not erase the person

The word “anonymous” is reassuring, but it does not tell you how anonymity was achieved. Which fields were sent? Were exact dates kept? How small can a group be? Did anyone independent test whether the records could be linked to another source? Without those answers, a user cannot know how much protection the word really offers.

The US Department of Health and Human Services says that even properly de-identified health data carries a small, non-zero risk of being linked back to a person. Saudi guidance is similarly clear: direct and indirect identifiers must be removed, the risk of re-identification must be assessed, and the method must be revisited as technology changes.

Australia offers a useful example. In 2016, its Department of Health released a sample of Medicare and prescription claims after de-identifying it. Identifiers were encrypted, geography was made less precise, dates were shifted, and rare items were removed. Researchers still broke the protection around provider numbers and said they had linked a small number of distinctive patient histories to public information with high confidence. The dataset was withdrawn, and the privacy regulator found flaws in the de-identification and risk assessment.

That case does not mean users of Shotsy or GlucoPal can be identified. It proves a narrower point: good intentions are not enough, and the word “anonymous” cannot replace an explanation of the method.

To be fair, analytics can be useful

Most founders and product managers are not looking through one person’s health record. In my own experience building B2C and B2B software, teams usually want broad answers: where do people get stuck, which features help, what breaks, and what should we build next?

When little data is collected, access is controlled, results are grouped, and qualified people test the anonymisation, analytics can be useful with less risk. Shotsy also says it excludes names, email addresses, and free text from its anonymous US iOS data, lets users turn collection off, and does not try to identify them again.

Local storage has a cost too. We cannot quietly see every failure as it happens, and on Android we cannot restore a lost health history unless the user exported a backup. Privacy does not make every part of the product easier. I believe it is worth the trade-off because Mounjari does not need your health timeline to do the job it was built to do.

But companies do not stay the way they started

A founder may be careful today and the whole team may mean well. Then the company changes. A new investor arrives, the product is acquired, or the assets are sold after the business fails. Data can move into hands the user never chose.

Shotsy’s policy, like many technology policies, says information may transfer during financing, a merger, an acquisition, bankruptcy, or an asset sale. In 2025, the US Federal Trade Commission warned about the sale or transfer of 23andMe customers’ sensitive information during bankruptcy and stressed that privacy promises do not disappear when ownership changes.

Someone may buy Mounjari one day, and a future owner could change the app. But that buyer cannot inherit a historical database of our users’ doses, symptoms, and weight because we never collected it. Real privacy should not depend on the character of the person running the company today.

What Mounjari actually sends

If by “Mounjari collects nothing” you mean the health history you record inside the app, that is true. We do not receive it. Accuracy still matters, so here is the small amount of non-health data needed to run subscriptions and the app, plus anything you choose to send to support.

We do not send the value of any health entry—the dose amount, symptom, weight, nutrition, or note—to product analytics or to an external crash-reporting service. We do not send a general log of the screens you open. The iOS exception is RevenueCat’s subscription-screen impression record: its internal ID can identify the paywall context, such as onboarding, dose, weight, more options, or a follow-up offer, but not the health value you entered.

• RevenueCat receives a random App User ID, subscription and purchase information, basic technical and language details, and the IP address, from which it may infer the country. On iOS, it also receives a record each time a subscription screen is shown. The internal screen ID can identify why the paywall appeared—for example during onboarding, after a dose or weight limit, or for a follow-up offer—but it does not include the dose, weight, symptom, note, or any other health value. RevenueCat may also receive Apple Ads data showing whether the install came from an App Store ad, so we can measure our campaigns.
• When the app opens, it asks a service we host through Cloudflare for its current configuration. The request includes the platform, app version, language, and locale. Cloudflare may keep an operational log with the IP address, request method and URL, response status, and the network details needed for security and troubleshooting for no more than seven days. Every copy of Mounjari uses the same shared key. The request contains no personal Mounjari ID or health entry, and we do not write it to a user analytics database.
• If you send feedback from inside the app, the form tells you what will be included: your message, the type of feedback, app and device details, language, platform, and a RevenueCat support ID if one exists. If you contact support through the website or by email, we process your name, email address, message topic, and message. Neither path attaches your doses, symptoms, weight, or health notes. We receive health information only if you type it into the message yourself.
• Website and download-link measurement are separate from the app and explained in the privacy policy. They cannot read the health record stored on your device.

What I still ask you to trust me about

I would like Mounjari to undergo an independent privacy and security audit. That has not happened yet. I will not present this article as if it were a certificate from a neutral third party, and I do not want to hide behind pages of legal language.

For now, you have our published policy, the specific explanation above, and my word as Mounjari’s founder. Yes, I am asking for some trust. I hope that saying exactly what we collect, what we do not collect, and why we chose not to possess your health history gives you a good reason to offer it.

What Shotsy says about its data

Shotsy’s policy says some US iOS users may contribute anonymous experience data for broad trend analysis. Its examples include injection counts, injection-site distribution, side-effect frequency, feature use, crashes, app version, and operating system. Users can turn collection off, and the company says the data excludes names, email addresses, and written notes.

On Android, Shotsy requires Google Sign-In and says app data is stored in Firebase. Its policy also lists measurement and analytics services including Firebase Analytics, Mixpanel, AppsFlyer, and Google Analytics.

What GlucoPal says about its data

GlucoPal’s policy says the main health record stays on the device or in the user’s own iCloud account. With permission, it may send limited health information for product analytics, including dose events and ranges, weight entries, and symptom categories. It also lists tools for crashes, performance, attribution, and subscription screens.

What MeAgain says about its data

MeAgain’s policy describes an account-based service and says it may collect contact details, device and usage information, health-tracking information, photos, AI chat transcripts, and community posts when those features are used. It also describes using information for analytics and product improvement, including AI and machine-learning models.

What GLPMate says about its data

GLPMate’s policy says health and profile data are stored on its servers and linked to an account. Its AI features may send messages, documents, voice input, transcripts, and relevant health data to OpenAI, Google, Anthropic, and Langfuse, and authorized staff may review conversation content for quality and safety.

The policy also lists Amplitude usage analytics, Firebase crash diagnostics, AdMob, and mobile attribution services, while saying some may be inactive in a particular build or region. GLPMate keeps progress photos on the device and lets users delete their account and server data.

What WiserApps says about GLP‑1 Tracker

The App Store page calls the app private by default, says health data stays on the device, and says no account is required. Apple’s privacy label also says the app may collect product-interaction, other usage, crash, and performance data that is not linked to the user for analytics and app functionality. It does not say that entered health records are sent with those events.

The privacy policy linked from that same page is far broader. It says WiserApps may collect contact details, IP addresses, IDFA and IDFV device identifiers, device names, purchase history, and app log data. It also discusses direct marketing, personalised advertising, cross-device tracking, advertising partners, accounts, and even biometric-data retention. Some of that language may come from a company-wide template rather than describe every field collected by this app. That uncertainty is precisely the problem: a health app’s policy should say plainly what this product sends, not leave the reader to reconcile a narrow store promise with a sweeping general policy.

That is why we built Mounjari

We did not build Mounjari because the stores lacked an app that could record a dose or a weight. We built it because we wanted a native experience across our devices and a health record the company does not own.

Mounjari’s privacy does not rest on my promise never to misuse your database. It rests on us not having that database at all. Yes, subscriptions and app operations require a small amount of non-health data, and we state it plainly. Yes, we still want an independent audit. But the heart of the protection is simple: Mounjari works without taking possession of your health history.