Skip to main content
← Back to All Projects
Mobile 2025

FlexR

Earned Wage Access and fintech platform for salary disbursements

↓ 95%
Transaction Failures
< 3s
Disbursement Speed
99.8%
Fraud Prevention

As a developer at Flexr, an Earned Wage Access app that empowers employees to access their earned pay before payday, my primary focus was to elevate the application's reliability, harden financial security, and ensure a seamless experience for every user. I took ownership of critical core flows—from identity verification to the actual wage access system—and ensured our infrastructure was robust and cost-effective.

Here is an overview of the key improvements I implemented and the results we achieved.

§1. Architecting the Earned Wage Access Flow

Because Flexr's entire business model revolves around allowing users to safely withdraw their earned wages before their actual payday, the withdrawal system needed to be flawless, instantaneous and strictly secure.

  • ›I was responsible for building the end-to-end flow and processes for the Earned Wage Access (EWA) system.
  • ›I implemented the logic that accurately calculates available balances based on days worked, manages the withdrawal requests, and safely processes payouts without double-debiting or failing during weak network connections.

§2. Integrating Identity Verification and Tiered Accounts

To onboard users securely and assign them dedicated bank accounts, I completely revamped the sign-up section.

  • ›I integrated the platform with Dojah, a robust third-party identity verification service.
  • ›Through this integration, users successfully passing initial verification are instantly assigned a virtual bank account classified as Tier 1.
  • ›I also built the upgrade pathways, allowing users to securely submit additional documents (like Passport , Driving License, NIN/BVN or other type of IDs ) to upgrade their profiles to Tier 2 and Tier 3. This allowed them to unlock higher transaction limits and account usage features seamlessly.

§3. Rebuilding the Bills and Payment Section

The original bills and payment architecture (handling airtime, data, and utility bills) was functioning, but the underlying provider was inefficient and costly for the business.

  • ›I conducted a technical and cost-benefit analysis and suggested migrating to a better, more cost-effective payment provider.
  • ›I completely rebuilt the Bills and Payment section around this new provider, managing the migration without disrupting the experience for active users.
  • ›This change significantly lowered operational costs on the company's end while improving the speed and reliability of utility payments.

§4. Enabling Seamless Bank Transfers and Deposits

Beyond wage access, it was essential for users to treat the app as a fully functional financial app where they could easily move their money.

  • ›I built and integrated the money transfer flows, enabling users to receive money directly into their Flexr accounts.
  • ›I also implemented the outgoing transfer system, allowing users to send money seamlessly and reliably to any bank account in Nigeria.

§5. Standardizing Financial Presentation

Because multiple developers had contributed to the codebase over time, money numbers were displayed inconsistently. Some screens hardcoded currency symbols, others showed confusing decimal points and transaction calculations were at risk of showing minor visual inaccuracies that confuse users.

To make sure financial numbers are always 100% accurate:

  • ›I created a centralized money formatting utility and required every single screen—from account balances and dashboards to digital receipts—to use it exclusively.
  • ›I added strict formatting rules so numbers, decimal places, and currency symbols look identical everywhere.

§6. Stopping Duplicate Payouts on Unstable Connections

On mobile connections, users frequently run into signal drops and latency spikes, especially when withdrawing funds in crowded areas. Without safety guards in place, if an employee tapped the withdrawal button and the screen lagged, tapping it again could trigger duplicate payouts or lock their advance allowance.

To make sure withdrawals happen exactly once:

  • ›I attached unique tracking tags to every salary advance request, allowing our servers to spot accidental double-taps and return the first successful result instead of paying out twice.
  • ›I set up an offline queue that safely holds pending requests if the internet drops and retries them automatically once the connection stabilizes.

§7. Protecting User Privacy and Hardening Biometrics

Because people check their salary and account balances in public places like offices and buses, keeping financial information private from nearby onlookers is essential.

To protect user data on the go:

  • ›I added privacy masking so sensitive account details are hidden by default and cannot be accidentally exposed or captured in screen recordings.
  • ›I overhauled the biometric sign-in flow so users can unlock the app instantly with their fingerprint or Face ID across both Android and iPhone devices, with safe fallback options if hardware sensors fail.

§8. Fixing the Mobile Build and Release Infrastructure

When I joined, the repository suffered from severe setup issues where code would compile on one developer's machine but fail on another, and outdated settings were causing warning flags on the app stores.

To fix our development foundation:

  • ›I cleaned up software version conflicts and stripped out unnecessary background permissions that were being flagged by Google Play.
  • ›I updated the underlying build configurations for both Android and iOS to the latest standards, clearing out legacy compilation bugs and enabling modern security features.
  • ›I integrated Codemagic and Shorebird to establish a continuous deployment pipeline, enabling constant and reliable updates.
  • ›I set up automated deployments to testing environments on both Google Play and iOS (TestFlight) so internal stakeholders could rigorously test new features before they went live.
  • ›I led the flawless rebranding of the entire app, renaming the application bundle and its architecture across operating system files and cloud configurations without dropping a single active user session.

§9. Ensuring Compatibility with Older Devices and Google's 16KB Requirement

Maintaining support across a fragmented ecosystem of Android devices is critical for our user base, many of whom rely on older, lower-end smartphones.

  • ›I optimized the app's memory footprint and execution paths to ensure it runs smoothly without crashing or lagging on older legacy devices.
  • ›I proactively addressed Google's new 16KB memory page size requirement for Android 15 by auditing our native libraries and updating our build configurations.
  • ›By correctly aligning our native memory pages to support both 16KB and 4KB architectures, I prevented catastrophic app crashes on newer devices while preserving flawless backwards compatibility.

§10. Keeping Users Safe When a Service Goes Down

When a third-party bank API went down, users used to hit frozen screens or outright crashes with no explanation, which is especially damaging to trust in a money app.

To handle failures gracefully:

  • ›I built robust safety nets and fallback screens so the app never freezes or crashes when an external service fails.
  • ›Instead of generic errors, users now get clear, actionable messages that explain what happened and what they can do next, keeping them calm and informed during outages.
← Back to All Projects Back to Top ↑