Your app is mostly built
Take over the current codebase, establish what works, and fix the blockers between the app and production.
- Reproducible builds
- Critical user journeys
- A scoped release plan
Build it. Fix it. Finish it. Ship it.
I’m Gohar Ali | Senior Mobile & AI Product Engineer
I’m Gohar Ali, a senior product engineer with 11+ years of software development experience. I work across Flutter, iOS delivery, full-stack systems, and AI products, especially when an existing app needs experienced engineering to reach production.
11+ years software engineering · Production mobile apps · Flutter + iOS · Full-stack + AI
What I do
Start with the situation your product is in. The engineering plan follows from the users, the current code, and what needs to ship.
Take over the current codebase, establish what works, and fix the blockers between the app and production.
Connect the mobile experience to the systems it relies on, from authentication and APIs to store releases.
Keep the speed of a working prototype while reviewing access rules, error handling, and deployment readiness.
Locate the failing build, platform configuration, integration, or production workflow and create a path to release.
Core services
I build and maintain Flutter products across the mobile client, backend integrations, and store release. My portfolio includes marketplaces, remittance, scheduling, and operational tools shipped for real users.
I bring senior software engineering and production Flutter-on-iOS experience to mobile products. The published apps below are Flutter applications; they are evidence of iOS delivery, not native Swift or SwiftUI client work.
I build AI products and connect useful model features to mobile workflows. The starting point is the task a person needs to finish, the data they can share, and the behavior when the model gets something wrong.
If the previous developer left, the backend is unreliable, or a release is blocked, the first task is to understand what is already working. I build a path from the current product to a verifiable release.
Why work with me
Not just prototypes: store releases, payments, maps, multi-tenant ops, and AI features with cost and latency in mind. Cross-sector delivery with a modern stack.
Toolkit
Portfolio
Client work

Luxury Fashion Marketplace | UAE / GCC
Authenticated luxury fashion marketplace connecting buyers and sellers: catalogs, multi-role workflows, payments, orders, and logistics across Flutter for iOS, Android, and web.
Stack: Flutter, iOS, Android, Web

FinTech | International Remittance
International money transfer app with secure onboarding, exchange rates, transaction tracking, and production mobile deployment for remittance workflows.
Stack: Flutter, iOS, Android, Web

Driving School Management | Scheduling SaaS
Production platform for driving schools: student management, lesson booking, instructor scheduling, progress tracking, notifications, and multi-role access.
Stack: Flutter, iOS, Android
Review the code, the users, and the current build.
Trace critical journeys across the app and backend.
Preserve working functionality and test the risky changes.
Validate the release and use production feedback.
Background
Tregix Pvt Ltd | Lahore, Pakistan
Fiedk | Remote
PetroPlay | Petroplus Sul Comércio Exterior | Remote
Confiz Limited | Lahore, Pakistan
Began professional career as an Android App Developer
Punjab University College of Information & Technology (PUCIT) | Lahore, Pakistan
Technical writing will follow original project examples. Explore the work and delivery approach behind it.
Visit insights →FAQ
Straight answers about codebase takeovers, native work, and release expectations.
Yes. I start with the current build, the critical user journeys, and the release blockers. The aim is to preserve working functionality and scope the changes needed to ship.
No. A rewrite needs a business and engineering case. First compare the cost and risk of repair with rebuilding and migrating the product.
Yes. I review identity, data access, error handling, payment flows, and deployment readiness. Useful code stays; risky boundaries get attention first.
I am currently building native Swift/SwiftUI apps. They are not live yet. The published client mobile portfolio is Flutter-based and should not be read as native Swift project history.
Engineering milestones can be planned, but Apple controls the review decision. Submission readiness, review feedback, and release verification need separate checkpoints.