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.
AI Araçları
Claude AI Nedir? Yazılımcılar İçin 2026 Kapsamlı Rehberi
Claude AI'ın 2026'daki yetenekleri, Claude Code, MCP, API kullanımı ve enterprise vakalarıyla yazılımcılar için kapsamlı Türkçe rehber.
Sonraki adım
Benzer bir proje planlıyorsanız, bağlamınızı netleştirip teklif akışını birlikte kurabiliriz.
Proje talebi oluştur