Partner fintech escrow: mobile flows made the backend assumptions visible
Turning escrow state, disputes, KYC, bank accounts, messaging, and notifications into mobile and operations flows — and what that exposed about the backend contract.
This phase was a useful kind of pressure test.
The backend could describe transaction states, disputes, messages, ratings, notifications, identity checks, and bank-account behavior. The mobile app had to turn those states into something a real buyer or seller could move through without calling support every ten minutes.
Those are different problems. A backend state that is technically correct can still produce a UI that leaves users stuck.
The work
This phase covered mobile authentication, transaction creation and detail, delivery proof, dispute creation and detail, messaging, profile, KYC, bank accounts, notifications, push state, and admin review surfaces.
That sounds like a list of screens. It was really a list of questions:
- What does the user see when a transaction is waiting on them?
- What does support see when a dispute has evidence?
- What should be blocked until identity checks are complete?
- Which messages belong to which transaction?
- What does a seller need before a delivery action is safe?
What mobile work actually does
Mobile exposes backend ambiguity.
If a transaction status is too vague, the screen feels vague. If a dispute state is missing a next action, the user gets stuck. If notifications are noisy, important events disappear inside a pile of updates.
This phase made the product contract tighter because every state needed a screen, every screen needed a next action, and every next action needed a backend boundary. That back-pressure from the UI is one of the more productive things about building mobile alongside the backend rather than after it.