Making an unstable production app reliable.
Inherited a production app with memory leaks, excessive API calls and no state management.
- Engagement
- Full-time · Lahore, Pakistan · Hybrid
- Stack
- FLUTTER · BLoC · CLEAN ARCHITECTURE
- Problem
- A live Flutter codebase with memory leaks, excessive API calls and no state management layer.
- Decision
- Refactored to Clean Architecture with BLoC instead of patching the symptoms one at a time.
- Outcome
- Cut unnecessary API calls by around 40% and moved state out of the widget tree entirely, in four weeks. The app stopped degrading over the course of a session — the failure the client had actually hired me for.
What was inherited
The app was already live and already had users. It leaked memory, it called the API far more often than it needed to, and it had no state management layer worth the name — screens held their own state and reached for data whenever they happened to rebuild.
That combination produces a specific failure pattern: the app is fine for the first few minutes of a session and degrades from there. It is also the pattern that is hardest to argue about, because every individual screen looks defensible on its own.
Why a refactor and not a patch list
Patching this class of problem screen by screen tends to move it rather than remove it. Each fix is local, the interactions between screens are what actually leak, and the list never shortens.
All the major modules were refactored to Clean Architecture with BLoC instead: one direction of data flow, state owned outside the widget tree, and network calls that happen because something asked for them rather than because a widget rebuilt. The UI was rebuilt on top of that rather than adapted to it.
Beyond the refactor
A chatbot layer was integrated into the same app, and the delivery assignment flow was fixed working alongside the backend engineers who owned that service — the bug crossed the client and server boundary and could not be closed from one side.
The numbers, and what they are worth
Unnecessary API calls fell by roughly 40% over four weeks. That one I counted, by comparing request volume for the same user journeys before and after.
This page used to carry a second figure beside it: performance and stability improved by around 70%. I have removed it. Performance and stability are two different properties measured in different units, and no instrument produced that number — it was an impression, rounded. The honest version of the same claim is qualitative: the app stopped getting slower the longer a session ran, which was the complaint that started the engagement.
What is left is still internal to a private app. Naming the client does not make it auditable from outside — you have only my account of it. Treat it as that, and treat the store links and public repositories elsewhere on this site as the part that holds up without trusting me.
Other engagements
I build AI features into production mobile apps, and stabilise the apps underneath them. See what working together looks like.