About the Client
A large fintech organisation running a banking super app: one application where customers manage accounts, deposits and loans, pay bills and fines, track spending and buy partner products.
Challenges
The product existed and had users. That is a harder starting point than a blank page: you inherit the decisions, the defects and the customers who notice both.
- A backlog of defects in live online banking, affecting real money.
- A notification system that did not behave consistently: in a banking app, a missed or duplicated notification is a support call at best.
- A wide feature surface: transfers, automatic payments, receipt scanning, fines, spending analysis, marketplace, voice assistant.
- Integration with the bank’s whole ecosystem, where each connected service has its own failure modes.
Our Approach
We started where the pain was: finding, reproducing and fixing defects in the existing product. Reproducing a bug in a banking flow is most of the work: the conditions involve a specific account state, a specific provider response and often a specific moment.
Once the defect rate was under control, the client handed us the backend of the application. We built it on Spring Boot, with the integrations the super app depends on: payments, messaging, file storage, push notifications and delivery coordination.
The notification system was rebuilt rather than patched. Push delivery in a financial product needs to be reliable and idempotent: the customer should be told once that their payment went through, not twice, and never not at all.
Results
- A large backlog of defects cleared from the live product.
- Notifications made consistent and predictable across the app’s flows.
- Backend delivered and integrated with the bank’s ecosystem services.
- The client moved us from fixing to building: the clearest signal that the first phase worked.
Technology Stack
- Backend: Java (Spring Boot, Spring Data, Spring Security) and Python (FastAPI, Django)
- Frontend: React, Next.js
- Test automation: Playwright
- Integrations and infrastructure: Liquibase, Amazon S3, Amazon SNS, Firebase Cloud Messaging, Twilio, Twilio SendGrid, Stripe, Onfleet
Team
The engagement ran with four developers, one QA engineer and one test automation engineer. A small team is the right shape for this kind of work: the codebase already existed, so most of the effort went into reading it, reproducing defects and shipping narrow fixes rather than building new modules in parallel.
Business Impact
This is the engagement shape we see most often in fintech: a product that shipped, grew, and started costing more to run than to build. Stabilising it first and then extending it is cheaper than a rewrite, and it keeps the users the product already has.