#BuildInPublic for the RevenueCat Shipaton 2026. RentDera is my entry, and I'm sharing the whole messy journey in public — wins, crashes, and gut-punches like the one below. This post is part of that trail. The setup Today I shipped v1.1.0 of RentDera, my rent-management app for landlords built with Expo + React Native. It was a big release: Edit properties, units, and tenants after creation Custom & recurring charges on dues Profile pictures Password reset from the login screen Email verification for new accounts Sign in with Google (alongside email) Multi-currency support A Nepali language option I published at 5 PM and left to enjoy the Janmashtami festival. That's when everything went sideways. Bug #1: The app crashed on launch Within 30 minutes, closed testers reported the app crashing immediately. The cause was almost embarrassingly small: I forgot to add one environment variable to my production build: EXPO_PUBLIC_LEGAL_BASE_URL In development, the variable was set in my local .env, so everything worked. In the published build, it was undefined — and the code that read it blew up on startup. The real lesson: a missing env var should fail loudly at build time, not silently ship and crash users. This is exactly why RentDera routes every env access through a single Zod-validated module that throws on a missing or invalid variable: // src/lib/env.ts (simplified) import { z } from "zod"; const schema = z.object({ EXPO_PUBLIC_API_BASE_URL: z.string().url(), EXPO_PUBLIC_LEGAL_BASE_URL: z.string().url(), // <-- the one I forgot to provide }); // Fails fast: if a var is missing, this throws immediately. export const env = schema.parse({ EXPO_PUBLIC_API_BASE_URL: process.env.EXPO_PUBLIC_API_BASE_URL, EXPO_PUBLIC_LEGAL_BASE_URL: process.env.EXPO_PUBLIC_LEGAL_BASE_URL, }); The validation was doing its job — it did crash because the value was missing. The gap was in my CI/release pipeline, where the variable was never injected. Validation catches bad values; it can't invent values you never provided to the build. I rebuilt, republished at 6 PM, and headed back out. Bug #2: "Sign in with Google isn't working" Then a tester called: the shiny new Google Sign-In wasn't working. I came home at 9 PM and started reading server logs. Nothing conclusive yet — Google Sign-In on native has a lot of moving parts (OAuth client IDs per platform, SHA-1 fingerprints on Android, the release keystore differing from debug). Still investigating this one. The part that actually hurt: losing the testing streak To publish to the Play Store as an individual developer, Google requires 12 testers active for 14 consecutive days in closed testing. I was on day 5. I had my 12 testers yesterday. Tonight, I refreshed the Play Console and saw one tester had opted out. The streak resets. There's no appeal, no recovery — you start counting again. A production crash you can hotfix in an hour. Lost days you can't get back. That stung more than either bug. Takeaways for solo mobile devs Validate env vars and verify your release pipeline injects them. Fail-fast validation is necessary but not sufficient — the CI/EAS build must actually supply every variable. Always smoke-test the production/release build, not just the dev build. Native OAuth, signing, and env handling all differ between the two. Over-recruit Play Store testers. With a 12-tester / 14-day requirement, a single opt-out can reset weeks of progress. Build a buffer. Shipping is humbling — keep shipping anyway. Off to find my 12th tester. If you'd like to help test a real-world rent-tracking app, drop a comment. 🙏 I'm building RentDera in public as my RevenueCat Shipaton 2026 entry — follow along for the next chapter (including whether I ever recover that testing streak). 🚢 Full v1.1.0 changelog: https://rentdera.com/changelog #BuildInPublic · #Shipaton · Built with Expo + React Native.