How Sentry Made Me a Better Product Manager

I Built an App I Wasn't Supposed to Build

I'm a Product Manager. My job is writing PRDs, product solutioning, and closely work with engineers and business team. Building apps is not my job.

But when I was explaining SIPs and retirement math to friends on call, and found that the existing apps were either too shallow or full of upsells. So I built GuideFin, a React Native app for Indian investors. Expo on the front, Supabase for login and data, a small server on Railway for the heavy math.

I launched v1.0 with zero monitoring. When something broke, I only found out if a user bothered to message me. Most didn't. They just left.

Adding Sentry fixed that. It became my feedback loop — a user telling me "your app broke" without having to say a word.

Setup Took less than 20 Minutes

I expected pain. I got one block in app.json:

["@sentry/react-native/expo", {
"url": "https://de.sentry.io/",
"organization": "finthinkhub",
"project": "guidefin"
}]


And a few lines of init code:

Sentry.init({
dsn: SENTRY_DSN,
tracesSampleRate: 0.2,
profilesSampleRate: 0.2,
sendDefaultPii: false,
enableAutoSessionTracking: true,
enableNativeFramesTracking: true,
});


Three decisions hiding in those few lines, made with my PM hat on:

sendDefaultPii: false — no personal data. GuideFin handles money-related inputs, so I strip fields like expense inputs before anything leaves the phone. If I don't need it to fix a bug, I don't send it.

tracesSampleRate: 0.2 — sample only 20% of sessions for performance data. Enough to see patterns, without burning my free quota.

The EU region (de.sentry.io) — my users are in India, but I wanted to be careful about where the data lives.

I also added a test function that fires a fake error on demand. Fire it once, see it land in the dashboard, remove it. Cheap insurance against a silently broken setup.

The White Screen Problem

The worst bug in a mobile app is the one where the user sees a blank white screen and closes the app. You never hear about it.

I wrapped the whole app in an error boundary — a safety net that catches a crash and tells Sentry where in the screen tree it happened. That "where" matters. Users told me "the app froze or not working." That's all I had. Sentry showed the exact screen and component: the goal projection screen was choking on an empty value from saved state. Fixed on same day.

Not All Errors Should Wake You Up

Building the goal projection feature taught me the most useful idea in this whole journey: errors come in two kinds.

Some errors are normal. A user's session expired. They're on a train and the network dropped. For these, the app quietly falls back to doing the math on the phone, and Sentry just gets a small note — a breadcrumb saying the fallback happened.

Some errors are not normal. The server returned garbage. The response wouldn't parse. Those get captured loudly, tagged with the module and operation, so I can see them piling up in the dashboard.

Now every spec I write starts with one question: which failures are normal here, and which ones should wake me up at 2am?

Breadcrumbs Are the Replay

Every screen visit and tap in GuideFin drops a breadcrumb. When a crash report comes in, I don't just see a stack trace. I see the path: opened Portfolio → tapped Goals → created a goal → set allocation → crash.

PostHog shows the big-picture funnels. Sentry replays one user's bad day. You need both.

The Bug That Only Happened on Cheap Phones

This is my favorite Sentry story while building Guidefin, because Sentry solved it by staying silent.

Users on mid-range phones — a Samsung Galaxy F23, a Redmi Note 12 Pro reported that the Mutual Fund and Goals screens would freeze. A bottom sheet would slide up (a filter, or a form) and then the screen just stopped responding. No crash. No error in Sentry. On my Samsung S23, everything worked perfectly, every single time.

A bug you can't reproduce, on phones you don't own, that leaves no trace. That's the nightmare.

I tried connecting a test phone to my laptop to read logs. The wireless connection kept dropping. So I flipped the plan: instead of attaching a debugger to the app, I made the app debug itself through Sentry.

For one diagnostic build, I turned tracing and profiling up to 100% and added a little homemade watchdog — a timer that pinged Sentry whenever the app's JavaScript was stuck for more than 1.5 seconds, tagged with the screen name.

The first reports looked crazy: "blocked for 75 seconds." But the breadcrumbs told the real story — screen off, app in background, 75 seconds, app reopened. The phone had simply put the app to sleep, and my watchdog mistook waking up for freezing. One fix later, it stopped crying wolf.

Then the real freeze happened on the F23. And the watchdog said... nothing.

That silence was the answer. Breadcrumbs showed taps were still being recorded during the freeze — so my JavaScript was alive and well. The problem was on the other thread, the one that draws the screen. The bottom-sheet library's animations were too heavy for a mid-range chip. My flagship phone just powered through it; the cheaper phones couldn't.

The diagram shows the deduction: the watchdog watches the JS thread, the JS thread was fine, so the fault had to be somewhere the watchdog wasn't looking — the UI thread.

The fix: lighter backdrop animation, no constant height re-measuring, fewer gestures on the heavy form, and pausing the ad carousel while a sheet is open. Then I deleted all the diagnostic code. From "can't reproduce" to fixed: one working day.

The lesson stung. My phone is a lie. Most of users are on ₹15–25K phones. A feature that works on a flagship hasn't been tested. it's been demoed.

The Bug Nobody Reported

After three months in production, I checked the data. One recurring error stood out: a crash in the portfolio tab that only hit users who had never added any assets.

Zero users reported it. They just stopped opening the portfolio tab. Without Sentry, I would have read that drop-off as a UX problem and redesigned the screen — never finding the real cause. Sentry found it in ten minutes.

What I'd Tell Every PM Who Ships

Silent failures are your biggest retention risk. A visible error at least invites a retry. A silent one quietly kills trust.

Error rate is a product metric, not an engineering metric. I track it next to retention. I've rolled back features twice because of Sentry spikes, before a single complaint arrived.

And absence of evidence is evidence. The most valuable signal in my hardest bug was a watchdog that didn't fire. Knowing what your tools would catch lets you reason about what their silence means. That's not an engineering skill. It's a thinking skill — and PMs need it too.

You don't have to write the integration yourself. But look at the error dashboard every week, the same way you look at your funnels. It's the closest thing to users telling you the truth.

Huge thanks to Sentry — it turned invisible failures into a feedback loop and made me a better PM in the process. Most of the stories above simply wouldn't exist without it.

GuideFin is a personal finance app built with React Native, Expo, and Supabase. If you're a PM thinking about building your first app — the stack is friendlier than you'd expect.

Try GuideFin: Download on Google Play