#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.

Top comments (0)