Technical Deep Dive · HEROIC Guardian
Rebuilding an unstable cybersecurity app into a reliable Flutter product
HEROIC Guardian was unstable when I worked on it. I redesigned pages and functionality, stabilized modules, moved scattered UI logic toward Clean Architecture and BLoC/Cubit, and handled product-critical areas including IAP, 2FA, identity protection, analytics, Crashlytics, release quality, and store growth work.
Starting Point
The app needed stability, clearer product flows, and a structure that could survive growth
The earlier implementation was unstable and had too much logic scattered through UI and `setState` usage. My work was not only screen implementation. I had to understand the product, redesign the user-facing flows, clean up module responsibilities, and centralize decisions so features like subscriptions, identity protection, breach monitoring, privacy scan, alerts, dashboard, auth, and profile flows could be maintained more safely.
I treated the work as product engineering: fix the architecture, make critical flows reliable, add analytics to understand where users drop off, monitor crashes, and connect release quality with ASO and growth decisions.
Architecture
Moving from scattered screen logic to a layered Flutter structure
Screens & Widgets
Redesigned pages as passive UI and reduced decision-making inside screens.
BLoC / Cubit
Moved events, states, loading, validation, and navigation decisions into state layers.
Use Cases
Separated product actions for auth, identity, privacy scan, subscriptions, alerts, and breach flows.
Repositories
Coordinated APIs, cache, Firebase, platform services, and product data responsibilities.
Workstreams
The main product problems I solved across the app
IAP flow and backend validation
I led the IAP solution because Apple and Google purchases cannot rely only on the app login account. I coordinated with the backend team and shaped the validation approach around transaction IDs.
Background identity status
Identity adding took time, so I first suggested sockets for status updates. When backend support was not available, I guided an API-based status-check approach so the process could continue without blocking the app.
Crash and module stabilization
I worked across unstable modules, improved page behavior, monitored crashes with Crashlytics, and connected release quality with production observations.
Analytics and drop-off reports
I added events to see where users were dropping off, where the app needed improvement, and submitted reports so product decisions were based on behavior instead of assumptions.
2FA, auth, identity, privacy
I worked on security-sensitive flows including authentication, two-factor flows, identity protection, privacy scan, breach monitoring, alerts, and profile-related user journeys.
ASO and release quality
I treated ASO as a product loop for Google Play and Apple App Store: audit the real feature pillars, map them to search intent, improve listing copy, redesign screenshot narrative, reduce review risk, and validate changes through analytics, user feedback, crash monitoring, and release quality.
Challenges & Resolutions
The difficult parts were not just coding screens. They were product and platform problems
Challenge 01
IAP could not depend only on app login.
A subscription purchase belongs to the Apple or Google purchase system first. That created a problem: the app account alone was not enough to safely decide purchase ownership and validation.
How I resolved it
I led the discussion with the backend team and shaped the solution around transaction-id validation. The goal was to validate the purchase from the platform transaction instead of trusting only the app login state.
What improvedThe subscription flow became safer to reason about because mobile, backend, and platform purchase identity were connected through a clearer validation path.
Challenge 02
Identity adding was slow and could not block the user.
Adding an identity could take time in the background. If the app waited on the same screen without a proper status mechanism, the user experience would feel broken or uncertain.
How I resolved it
I first suggested sockets so the backend could notify the app when the identity was added. When that was not implemented, I advised using an API status-check approach so the mobile app could keep checking progress in the background without freezing the experience.
What improvedThe app could handle a long-running operation more gracefully and keep the user flow moving while the background identity process continued.
Challenge 03
The app was unstable with scattered screen logic.
Many parts of the app were difficult to maintain because behavior was spread across UI code and repeated state handling patterns. This made new features and bug fixing risky.
How I resolved it
I visualized a cleaner structure and moved responsibilities into Clean Architecture layers: UI as passive screens/widgets, BLoC/Cubit for state, use cases for product actions, and repositories for API, cache, Firebase, and platform coordination.
What improvedThe product became easier to debug and extend because the app had clearer boundaries between UI, business decisions, and data operations.
Challenge 04
Product decisions needed real user behavior.
It was not enough to guess which screens or flows needed improvement. The team needed visibility into where users were dropping off and how releases affected the product.
How I resolved it
I added analytics events across important flows and used Crashlytics/release observations to connect engineering work with product reports. I submitted reports showing where users dropped off and where the app needed improvement.
What improvedProduct improvements became easier to prioritize because architecture work, crash monitoring, analytics, ASO, and release quality were connected into one feedback loop.
Modules
The work touched the product as a whole, not one isolated screen
The local project structure reflects the product scope: auth, subscription, identity protection, privacy scan, breach and breach monitoring, alerts, dashboard, family, support, profile, master data, and shared analytics. My contribution was to work across these areas as the mobile owner and make the app more stable, structured, and measurable.
FlutterClean ArchitectureBLoC / CubitFirebase AnalyticsCrashlyticsIAP2FAIdentity ProtectionPrivacy ScanASO
Outcome
A more stable, measurable, and growth-ready mobile product
The strongest confirmed outcome is the growth from early traction to 10,000+ downloads and steadily increasing. The engineering contribution behind that was broader than one feature: architecture cleanup, product flow redesign, analytics, Crashlytics, subscription reliability, identity status handling, 2FA/auth improvements, release quality, and ASO.
Known result: downloads increased from 200 to 10,000+ and steadily increasing.Contact
Ready to discuss senior Flutter, mobile architecture, or product engineering roles
Email: [email protected] · Phone: +91 95672 00188