Ongoing

Angel One fund-addition platform

Senior Android Engineer2025Ongoing6 people2 min read

Improved a high-trust fintech flow with in-app payments, configurable support journeys, cleaner state handling, and faster biometric authentication.

Overview

At Angel One, I work on Android surfaces where reliability is part of the product experience: fund addition, support navigation, biometric authentication, analytics, and service migrations.

Problem

Adding funds is a trust-sensitive flow. The product needed faster iteration on support journeys, fewer payment handoffs, and a cleaner Android architecture without increasing risk in a regulated environment.

Constraints

  • The flow handled money movement, so stability and user trust were non-negotiable.
  • Help content and support routes needed to change without waiting for app releases.
  • Payment behavior had to stay compatible with existing analytics and service contracts.
  • Authentication improvements had to preserve security expectations while reducing friction.

Approach

I rebuilt the Add Funds module around MVVM with Kotlin Channels and Flow, integrated 1 Click Pay for in-app completion, introduced a remote-configurable help navigation layer, and supported service and analytics refactors that made the surface easier to evolve.

Key decisions

Use Flow and Channels to model fund-addition UI events and state

Reasoning

The payment flow has asynchronous validation, SDK callbacks, and one-off UI events. Flow and Channels made those transitions easier to model, test mentally, and extend safely.

Alternatives considered
  • Extend the older event wiring with more callback branches
  • Push all orchestration into fragments and activity-level code

Make help navigation remote configurable

Reasoning

Support routes change more often than app binaries. Remote configuration let the product respond faster while keeping Android releases focused on code changes.

Alternatives considered
  • Keep help routes hardcoded in app releases
  • Depend on manual hotfix releases for content changes

Integrate in-app payments instead of relying on third-party UPI app hops

Reasoning

Keeping users inside the app reduced context switching and made the money movement experience feel more direct.

Alternatives considered
  • Continue external-app payment redirection only

Tech stack

  • Kotlin
  • Coroutines
  • Flow
  • Channels
  • MVVM
  • Android SDK
  • Analytics

Result and impact

  • ~500 ms faster
    Biometric latency
  • Removed for help-content navigation updates
    Release dependency
  • Enabled in-app fund addition with 1 Click Pay
    Payment UX

The work made a critical fintech journey faster to operate, easier to change, and more cohesive for users while leaving the Android codebase in a healthier shape.

Learnings

  • Fintech UX improvements work best when product clarity and defensive engineering move together.
  • Remote configuration is most valuable when it removes release pressure from operational content.
  • Architecture changes in live money flows need analytics, service contracts, and user trust considered together.

The throughline was trust. Users notice slow authentication and unnecessary payment hops immediately, so the engineering goal was to reduce friction while keeping the flow predictable and observable.

All projects