Why I Built Trackless Telemetry
I've been an indie app developer for over a decade. My app, Simple Pace Calculator, started as a scratch-my-own-itch project — I'm a runner and an engineer, and I couldn't find a pace calculator that worked the way I wanted. So I built one myself. The first version hit the App Store in 2014.
For the next ten years, I ran Simple Pace Calculator with zero analytics. I had no idea how many people used it, which features they cared about, or what I should build next. I just shipped what felt right and hoped for the best.
The Ad Experiment
Last year, I tried adding Google AdMob to monetize the app. After a year of running ads, I learned two things:
- The revenue wasn't worth it.
- I didn't like what I was doing to my users.
Every ad impression meant sending data about my users to Google. Screen size, device model, location, behavioral signals — all flowing to a third-party ad network so they could serve targeted ads. My users didn't ask for that. They just wanted to calculate their pace for a Saturday morning run.
So I pulled the ads out. But the experience left me thinking: maybe it's time I actually understood how people use this app.
Looking for Analytics That Respect Privacy
I started researching analytics options. I looked at Google Analytics, Firebase, Mixpanel, Amplitude, PostHog, Plausible, Fathom, TelemetryDeck — everything I could find.
What I discovered surprised me. Every single option I evaluated either:
- Collects persistent identifiers (user IDs, device IDs, install IDs)
- Uses device storage for tracking (cookies, localStorage)
- Enables cross-session linking
- Collects fingerprinting-capable data (exact device model, screen resolution, full user agent)
- Hashes identifiers instead of eliminating them (which still counts as personal data under GDPR)
Some were better than others. The privacy-focused web analytics tools like Plausible and Fathom are genuinely good — but they only count pageviews on websites. They don't support mobile apps, and they don't give you feature-level analytics, funnels, or error tracking.
I wanted analytics I could add to my app without feeling like I was betraying my users' trust. Analytics that wouldn't trigger a consent banner in the EU, wouldn't require an ATT prompt on iOS, and wouldn't send any data to a third party.
I couldn't find it. So I started wondering: is it even possible?
The Engineering Challenge
This is where the engineer in me got excited.
I spent most of my career writing real-time software for the automotive industry — systems where you have to be precise about what data you collect, how you process it, and what guarantees you can make. So I approached this as an architecture problem: what's the minimum data I need to understand how my app is being used, and can I collect it in a way that makes tracking individual users not just prohibited by policy, but architecturally impractical?
The answer turned out to be yes.
The key insight is that most of the analytics questions indie developers actually care about don't require tracking individuals:
- Which features do people use? You just need aggregate counts.
- Are people completing my onboarding flow? You need funnel step counts, not user-level journeys.
- Is my app fast enough? You need percentile distributions, not per-user timings.
- Are errors increasing? You need error counts by severity, not individual stack traces tied to users.
- What platforms are my users on? You need coarse breakdowns, not exact device profiles.
So I designed a system that collects only aggregate counts with coarse device context — platform, OS major version, device class (phone/tablet/desktop), country (from device locale, not IP), and language. No user IDs. No device IDs. No cookies. No fingerprinting data. No IP address processing.
The system doesn't just promise not to track users. It's built so that even if someone wanted to, it would be extremely difficult. There are no identifiers to correlate. No raw events to reconstruct. No high-entropy data to fingerprint with. The database contains only pre-aggregated statistical rows. You literally cannot query it to find out what any individual person did.
From Side Project to Product
As I built this for Simple Pace Calculator, I realized other developers probably had the same problem. Plenty of indie developers and small teams want to understand their apps without surveillance infrastructure. Plenty of companies in regulated industries need analytics that don't create compliance headaches.
And the privacy landscape is only moving in one direction. GDPR, ePrivacy, CCPA, Apple's App Tracking Transparency, browser anti-tracking features — every trend points toward a world where identifier-based tracking gets harder and more legally fraught.
So I decided to build Trackless Telemetry as a product that any developer can use.
What I Believe
I believe most companies don't respect user privacy as much as they should. Not because they're malicious — but because the tools they use are built on a foundation of tracking, and the path of least resistance is to go along with it.
I believe you shouldn't need to track individuals to build a great product. The aggregate patterns tell you what you need to know: what's working, what's not, where to focus.
I believe privacy should be an architectural guarantee, not a policy promise. Policies can change. Databases can be breached. Architectures that never collect the data in the first place can't leak what they don't have.
Trackless Telemetry is my answer to a question I asked myself as an indie developer: can I understand how my app is being used without compromising the privacy of the people who use it?
The answer is yes. And now it's available for every developer who's been asking the same question.