Open to Flutter roles — remote or on-site
First sketch to store release.
I'm Sohrab Ezzati, a Flutter developer based in Herat, Afghanistan. I carry a product through the whole journey myself: concept, architecture, implementation, testing and the store release. Two of mine are in production right now.
- Based in
- Herat, Afghanistan
- Focus
- Flutter · production mobile apps
- Experience
- 4+ years of Flutter
- Availability
- Open to roles — remote or on-site
Background
The short version.
I build mobile apps with Flutter, covering the full process from design and architecture to development, testing and release. Over the past four years, this has led to two products now in production: the customer app of an internet provider and a live TV streaming platform.
Both are built for Afghanistan, and that shapes the work more than any framework choice. The interface is Persian and right to left, dates follow the Jalali calendar, and the network can’t always be trusted. Much of the audience relies on mobile data that can be unstable, so offline behavior, retries and clear failure states are built into the app from the beginning.
My favorite part of the work is what happens behind the interface. When there was no suitable Dart client for MikroTik’s binary router protocol, I built one. When live scores needed to stay reliable while users moved between screens, I built reference-counted socket subscriptions. That foundation is what makes an app reliable in the real world.
Philosophy
What I hold to.
- 01
Decide the structure early
Good architecture makes everything easier later. I take the time to define clear boundaries early so the code stays easy to work with instead of needing a major rewrite later.
- 02
Design for the worst connection
An app should still work when the internet is unreliable. That means putting important rules on the router, retrying streams quietly, and refreshing data when the connection comes back.
- 03
Go below the framework when needed
Packages handle common use cases, but they don’t always cover what a product needs. When that happens, I build the missing layer instead of changing the product to fit a library. That’s how the router client and custom player controls came to life.
- 04
The release is part of the work
Store reviews, signing, staged releases, crash reports, and future updates are all part of building an app. The work doesn’t end when the features are finished; it continues as real users start depending on the product.
Toolkit
What I use.
Grouped by what it does, not by how many logos fit on a screen.
Mobile
- Flutter
- Dart 3
- iOS
- Android
- RTL & localization
- Custom video players
Architecture
- Riverpod
- Feature-first structure
- go_router
- Offline-aware design
- Optimistic UI
Networking & data
- REST (Dio)
- GraphQL codegen
- Socket.IO
- Binary protocols (MikroTik)
- Hive
- Local media caching
Realtime & push
- Firebase Cloud Messaging
- Deep links & universal links
- Live data over sockets
- Grouped notifications
Delivery
- App Store Connect
- Google Play Console
- Shorebird code push
- Force-update gates
- Feature flags (PostHog)
Product
- Design tokens
- Skeleton loading states
- Jalali calendar
- Persian typography
- Analytics
Contact
Let's talk about the work.
If you're hiring for Flutter, or you have a product that needs building properly, write me a few lines. I'm based in Herat, Afghanistan and open to remote.