LogeAfrica — Mobile Real Estate Marketplace.

Real estate listings in Bénin circulate informally — TikTok videos, Facebook posts, word of mouth — with no central place to filter by neighborhood, furnishing, or price, no reliable way to tell if a listing is still available, and no way to reach whoever posted it without leaving the platform and hoping for a reply.

Video-first feed architecture. Built a TikTok-style vertical feed (Expo + React Native) where each swipeable card is a listing — an uploaded photo, an uploaded video, or an embedded TikTok clip — backed by an Express/TypeORM API on PostgreSQL. Listings carry structured tags (property type, furnishing, access, transaction type) instead of free-text search, so filtering stays fast and consistent as sourcing scales.

AI-assisted content sourcing. Since most listings genuinely start as a TikTok video, built a discovery pipeline that collects candidates (TikTok search collection plus SerpAPI), runs each through an OpenAI enrichment step that extracts price, transaction type, and location with a confidence score per field, and either auto-publishes high-confidence candidates or routes them to an admin review queue — a human only has to look at the ones the model wasn't sure about.

In-app messaging, not a hand-off. Tenants message an announcer directly from a listing without leaving the app. A dedicated lightweight session layer (opaque tokens, not JWT) lets a visitor start a conversation without creating a full account first, and messages support voice notes recorded and played back natively.

Mobile money payments for premium alerts. Tenants can subscribe to instant search alerts (vs. a free weekly digest), paid for through FedaPay's mobile money rails (MTN, Moov) from inside the app, including a return bridge that lands the payer back on the app's own custom URL scheme — FedaPay only accepts https callback URLs, so a small web page does the final client-side redirect.

Challenge — making embedded video feel instant. TikTok's embed player exposes no usable raw-video API, so playback stays a WebView; the real problem was making a feed of them feel native — preloading the next two cards' players in the background (loaded, muted, not yet revealed) while the current card plays, then correcting for the fact that a backgrounded player can drift off frame 0 before it's tapped, by forcing a seek back to 0 and holding the reveal just long enough to hide the correction from view.

Challenge — shipping a real device build. Early EAS builds silently shipped without the production API URL baked in: the local .env file never reaches EAS Build's cloud archive, since it's gitignored and excluded from the project upload even with version control bypassed. Fixed by moving the required EXPO_PUBLIC_* values into eas.json's own per-profile env block — the one place a cloud build actually reads them from — and confirmed via the build log explicitly listing them as loaded.

Challenge — a native module migration mid-build. A device crash on the voice-recording flow traced back to expo-av's native module being unavailable on the installed SDK; migrated recording and playback onto expo-audio's hooks-based API instead, and adopted a defensive pattern (dynamic import, wrapped in its own try/catch) for other native-module-backed features so a stale build degrades gracefully instead of crashing the whole screen.

In hindsight: most of the hard problems here weren't the obvious ones (build a feed, call an API) — they were the seams between systems: a build pipeline that silently drops config, a video player that doesn't tell you where it actually is, a payment provider that doesn't speak your app's URL scheme. Getting those right is what makes the app feel solid.