The regular day of a startup juggles between two states, namely shipping or fixing.

You can catch any developer working at any time (day or night), they are usually pushing code to production as long as it is functional or fixing the code in production that they shipped after marking it as functional.

It’s funny, but this is what makes working at a startup fun.

This blog highlights the advantage of using sentry and Expo to push your code to production quickly.

Using Expo:

Using Sentry

npx expo install sentry-expo
npx expo install expo-application expo-constants expo-device expo-updates @sentry/react-native

Sentry.init({
  dsn:   <_YOUR_DSN_HERE_>,
  enableInExpoDevelopment: true,
  debug: true, // If `true`, Sentry will try to print out useful debugging information if something goes wrong with sending the event. Set it to `false` in production
  autoSessionTracking: true,
  enableNative: true,
});

After all

You can expect to have the fighting duo at your disposal in your startup arsenal.


There are many features of EXPO startups today uses, one specifically is ability to write code once, run everywhere and second, manage the CI/CD pipeline right from your terminal via EAS

I am working at a startup, using expo and integrated Sentry. We have faced realtime crashes, issues, solved the bug and shipped the solution literally in minutes because of our dynamic duo.

Here is how we were able to do so we faced during our fast iteration and faster shipment days.

  1. Sentry captures errors, exceptions, crashes, transactions, and generally anything that goes wrong in your application in real-time. Before our internal user decides to report the bug, we get the notification about it with a detailed report.

  2. There is in-depth stack trace on every issue that our user faced. It keeps history of all the events that happened before the actual code break and sends the event data to DSN

  3. This detailed dashboard help us to pinpoint the cause of error, we debug it , ship the solution and then move to improve debugging on the app by planning our actionmap for future and unforseeable bugs.

  4. There is a feature called tags, which give a detailed visual idea about the bug (like machine/device, OS version, API version, release version, environment ) and in Sentry dashboard one can customize a tag the errors based on the type of origin, an error particularly has.

You can debug the issue as fast as you understand it. The data about the issue only makes it faster to solve.

Debugging via Sentry is a great to way to understand the internals of a stack that we use and gives us opportunity to work on improving our understanding about the programming concepts and helps us design better systems. This has significantly helped our startup in having fast fixes and faster deployments.