Giriş: "Flutter biliyorum" yetersiz cevap
Flutter pazarı 2026'da olgunlaştı; bu pek çok freelancer ve ajansın "Flutter biliyorum" dediği anlamına geliyor. Ama Flutter bilmek ile production-quality Flutter ürün teslim etmek farklı şeyler. Birincisi tutorial seviyesi; ikincisi mimari + performans + test + teslim disiplini.
Bu yazıda Flutter geliştirici / ekip seçerken bakılması gereken 7 kriteri sıralıyoruz. Her kriter için somut sorular ve kırmızı bayraklar var. Doğru seçim 3-6 ay sonra fark eder; yanlış seçim 12-18 ay yeniden yazma demektir.
Genel ilke: portfolyo başlangıçtır, karar değil. Görsel güzel ekranlar atan ekiple, performans + bakım kalitesi getirenler aynı değildir. Süreç görüşmesinde kod kararlarının nasıl alındığını sorgulayın.
1. Portfolyo + canlı uygulama: gerçek mi, gösterim mi?
Portfolyo'daki ekran görüntüleri yeterli değildir; App Store / Play Store linki isteyin. Uygulamayı indirin, kullanın, performans hissini test edin. Açılış süresi nasıl? Scrolling akıcı mı? Animasyonlar 60fps mi?
Sorulacak sorular: (a) bu uygulamadan kim hâlâ kullanıcı? (b) kaç indirme aldı (gerçek sayı)? (c) hangi sürümleri canlıya çıkardınız?
Kırmızı bayrak: portfolyo'da "klon Instagram", "klon Uber" tarzında tutorial projeleri. Bunlar öğrenme alıştırmasıdır; gerçek müşteri projesi değil. Gerçek proje = canlı app store linki + müşteri onayı.
İdeal: ekibin son 12 ayda en az 3 farklı sektör için Flutter uygulama teslim etmiş olması. Çeşitlilik = adapte olabilirlik. Tek sektör tek tip kalıp.
2. Mimari karar: state management + folder yapısı
State management seçimi Flutter projesinin omurgasıdır. Ekibe sorulacak: "Hangi state management'ı kullanıyorsunuz, neden?" Cevap olarak BLoC / Riverpod / Provider + gerekçe gelmeli.
Riverpod 2026'da en popüler tercih (BLoC'tan daha az boilerplate, Provider'dan daha güçlü). Ama ekip projeden projeye farklı mı, yoksa hep aynı mı kullanıyor? Bilinçli farklılık iyi; kararsızlık kötü.
Folder yapısı: feature-first (her özellik kendi klasöründe:
features/auth/, features/orders/) modern standart. Layer-first (models/, screens/, services/) eski stil; orta-büyük projelerde yetersiz kalır.Sorma yöntemi: ekipten 15 dakikalık pair-programming isteyin. Mevcut bir projede yeni feature ekliyormuş gibi yaparken siz izleyin. Folder yapısı, naming, refactor refleksleri her şeyi söyler.
3. Performans: 60fps disiplini
Flutter cross-platform olduğu için performans doğru kurulduğunda native'e yakın, kötü kurulduğunda belirgin yavaş. Hangi tarafta olduğunu test etmeden imzalamayın.
Sorulacak sorular: (a) hot reload + DevTools profiler ile performans nasıl ölçülüyor? (b) Flutter Inspector'da widget rebuild sayılarına bakıyor musunuz? (c) büyük listeler için ListView.builder + pagination nasıl kuruluyor?
Tipik tuzaklar: tüm uygulamada
setState kullanmak (her küçük değişiklikte tüm tree rebuild olur), build içinde her render'da yeni Object yaratmak, resimleri optimize etmemek (cached_network_image + thumbnail).İdeal cevap: "Profiling DevTools ile yapıyoruz, kritik sayfalar için
const constructor disiplini, ListView'lerde itemExtent + cacheExtent, image placeholder'ları + lazy loading, 60fps için her sayfada inspector raporu."4. Test + CI/CD: kalitenin sigortası
Flutter'da test piramidi: unit test (business logic), widget test (component davranışı), integration test (kullanıcı senaryosu). Ekibe sorulacak: hangi seviyelerde test yazıyorsunuz?
Cevap "manuel test ediyoruz" ise kırmızı bayrak. Manuel test ürün küçükken iş görür; 5+ ekran sonrası regresyon kâbusa döner.
CI/CD setup: GitHub Actions / Bitrise / Codemagic ile her PR'da: (a) build çalışıyor mu, (b) test geçiyor mu, (c) lint/format kuralları, (d) staging build otomatik dağıtım. Manuel deployment 2026'da kabul edilemez.
Sorulacak: "Son projenizi gösterin, GitHub Actions yaml dosyasında ne var?". Şeffaf ekip gösterir; gizleyen ekip ya yok demektir ya hatalı.
5. Native entegrasyon yetkinliği
Flutter "sadece UI" değildir; gerçek projelerde native entegrasyon gerekir: push notification (FCM + APNs), biometric auth, camera + image picker, in-app purchase, deeplink + universal link, native SDK'lar (analytics, payment).
Sorulacak: "Daha önce hangi native modülleri kullandınız? Method channel yazdınız mı? Hangi paket bakım dışına düştüğünde ne yaptınız?"
Kırmızı bayrak: "Native bilmiyoruz, sadece pub.dev paketleri kullanıyoruz" cevabı. pub.dev paketleri %80 senaryoyu çözer; %20 için custom native bridge gerekir. Bu yetkinlik yoksa proje tıkanır.
İdeal: ekipte Swift / Kotlin temel bilgisi olan en az 1 kişi. Gerekli platform-specific kod yazılabilir; gerekmedikçe yazılmaz.
6. İletişim + demo ritmi: teslim güveni
Teknik yetkinlik kadar iletişim disiplini önemli. "Hangi sıklıkta demo, hangi format, kim katılır?" sözleşmeden önce netleşmeli.
İdeal yapı: (a) haftalık 30 dakikalık demo (Zoom/Google Meet), (b) demo sonrası yazılı özet (yapılanlar + kalan + risk), (c) her sprint sonu staging build'e müşteri erişimi, (d) Slack/Teams günlük kanalı, kritik bug için 2 saat yanıt SLA'sı.
Kırmızı bayrak: "Bittiğinde göstereceğiz" cevabı. Bu cümle 6 ay sonra "sürpriz teslim" demektir; %90 ihtimalle beklentiyle uyumsuz çıkar.
Sorulacak: "Geçmiş bir projede haftalık demo örneği gösterebilir misiniz?" (gizlilik anonimleştirilebilir). Demo formatı + raporlama disiplini son derece şeffaftır; iyi ekip gizlemez.
7. Sözleşme + kod sahipliği
Ne kadar iyi geliştirici olursa olsun sözleşmeyi atlayan ekiple çalışmayın. Kod sahipliği size ait mi? Repository sizin GitHub hesabınızda mı? Tasarım dosyaları (Figma) sizinle paylaşılıyor mu?
Kritik maddeler: (a) tüm kaynak kod + tasarım + dokümantasyon müşteri mülkiyeti, (b) 30-90 gün ücretsiz garanti, (c) teslim sonrası bakım sözleşmesi opsiyonel + saatlik şeffaf fiyat, (d) kritik bug SLA (24 saat fix).
Ödeme yapısı: peşinat + milestone (ör. %20-30-30-20). "Hepsi peşin" istemek kırmızı bayrak; "hepsi sonra" da bağlayıcılık eksikliği. Sağlıklı denge milestone-bazlı.
Vendor lock-in kontrolü: standart stack (Flutter + standart paketler + Firebase / Supabase / kendi backend) kullanılıyor mu, yoksa ekibin kendine özel framework'ü mü? İkincisi gelecekte başka ekiple devam etmeyi imkansızlaştırır.
Sonuç: 7 kriteri 1 saatlik teknik görüşmede netleştirin
Sözleşmeden önce 1 saatlik teknik görüşme isteyin. 7 kriteri tek tek sorun. Cevaplara bakıp "evet, bu ekip sağlam" hissi alıyorsanız ilerleyin; bir kriter bile zayıfsa bekleyin ve başka teklif değerlendirin.
Maliyet farkı önemli ama en ucuz teklif çoğu zaman en pahalı seçim olur. Düşük fiyat = kısa vadeli iş = yüksek teknik borç + 6 ay sonra yeniden yazma. Orta fiyat + 7 kriterden 6'sını veren ekip en güvenli yol.
Mobil uygulama projeniz için Flutter geliştirici / ekip arıyorsanız mobil uygulama geliştirme sayfamız üzerinden iletişime geçebilirsiniz; bu 7 kriterin hepsi sözleşmemizin parçasıdır.
İlgili yazılar
Aynı kararı destekleyen diğer yazılar
Teklif Süreci
Teklif Almadan Önce Proje Nasıl Hazırlanır?
Daha hızlı ve daha isabetli teklif almak için 6 başlık altında hazırlık checklist'i: hedef, kapsam, referans, bütçe, KVKK, dokümantasyon. İyi hazırlık teklif kalitesini ikiye katlar.
Ajans Seçimi
Yazılım Ajansı Seçmeden Önce Sormanız Gereken 10 Soru
Ajans seçimi referans + portfolyo değil, teslim modeli + karar kalitesi + sözleşme nettiğidir. Yanlış kararın faturası 6-12 ay sonra çıkar; doğru sorular en başta sorulur.
Maliyet Analizi
Mobil Uygulama Maliyeti 2026: Fiyatı Gerçekte Ne Belirler?
200K mı, 2M mı? Mobil uygulama maliyeti 7 kalemde belirlenir: kapsam, backend, entegrasyon, native ihtiyacı, test+güvenlik, bakım, fazlı yaklaşım. Her kalem için somut aralıklar.
Sonraki adım
Benzer bir proje planlıyorsanız, bağlamınızı netleştirip teklif akışını birlikte kurabiliriz.
Proje talebi oluştur