SurgePay
Building and shipping multi-currency fintech on mobile.
- Role
- Frontend Engineer
- Context
- SurgePay, product team
- Timeline
- May 2025 to present
- Platforms
- iOS, Android
- Status
- Primary metric
- $1M+transaction volume in the first six months
Overview
SurgePay is a mobile money app for people who hold and move more than one currency. Users keep naira and US dollar wallets, open virtual USD cards and US virtual accounts, send money to banks or by QR code, swap between currencies, save, and buy fractional US stocks.
It also holds stablecoins. Users receive and send USDC and other tokens across networks including Stellar, Solana and Base, and move between stablecoins and fiat inside the same send flow.
Every account is verified through identity checks that differ by country, and the app ships to the App Store and Google Play. Within six months of launch the mobile flows had moved over $1M in transaction volume, and SurgePay secured six-figure backing from the Stellar Community Fund (SCF).
My role
I am the frontend engineer on the mobile app and web app. I implemented the React Native application end to end: wallets, cards, send and swap flows, KYC, savings, investing, notifications and authentication. I integrate the backend APIs the team builds, and I manage builds, over-the-air updates and store releases.
The challenge
In a payments app the interface is the last line of trust. Identity checks, card issuing, blockchain networks and bank transfers each come from a different provider, and every one of them has to look like one calm, correct product on a phone.
- Real money: every payment state on screen has to match the ledger.
- Identity checks differ by country and run through a native SDK.
- Staging and production builds must never be confused.
- Two stores, two review processes, one codebase.
Architecture
React Native app
Built by me
Server-state layer
Built by me
SurgePay APIs
Built by the team
Providers
Third party
Engineering challenges
Two native SDKs, one manifest
- problem
- Adding the Smile ID SDK for face verification broke the Android build.
- constraint
- expo-camera (used for QR scanning) and the Smile ID SDK both declare which ML Kit models the app needs, with different values, and Android’s manifest merger refuses to pick one.
- approach
- I wrote an Expo config plugin that declares both models, barcode and face, in the app’s own manifest and tells the merger to use that value, so the fix is reapplied on every prebuild instead of living in a hand-edited native folder.
- result
- QR scanning and face verification ship together in one build, reproducibly.
Staging and production side by side
- problem
- Testers need staging builds while customers run production, from the same codebase.
- constraint
- A build that points at the wrong environment in a money app is not a cosmetic bug.
- approach
- Separate EAS build profiles for development, preview, internal TestFlight and production, each with its own API environment and update channel, so the environment is decided at build time and production builds auto-increment their version.
- result
- Staging and production are distinct artefacts, and a store build cannot point at staging.
Moving push notifications onto Firebase
- problem
- Push notifications ran through Expo’s push relay, and the backend needed to send through Firebase directly.
- constraint
- Tokens refresh, users log out or get suspended, and a notification tapped while the app is closed still has to land on the right screen.
- approach
- The app now registers raw Firebase Cloud Messaging tokens after sign-in, handles token refresh and foreground messages, deletes the token on logout or suspension, and routes notification taps through deep links. expo-notifications stays only for permissions and the Android channel.
- result
- Notifications arrive through Firebase in both environments and open the screen they are about.
Cutting cold-start time
- problem
- The app took about 4.2 seconds to become usable from a cold start.
- constraint
- A payments app has to restore a secure session before it can show a balance, so some launch work cannot simply be skipped.
- approach
- I measured what ran before the first usable screen and moved everything that did not have to block it until after the first render.
- result
- Cold start dropped to about 2.9 seconds.
Outcome
$1M+
transaction volume in six months
4.2s → 2.9s
cold start, approximately
iOS + Android
production deployment
In fintech the work that users never see, such as environment separation, release channels, monitoring and end-to-end tests, is what lets the visible work be trusted.