Yapay Zeka Destekli Mantıkla Mobil Uygulama Yapmak: Fikirden Yayına

Fikri Netleştirin: Kullanıcı, Değer ve MVP Kapsamı

İyi bir uygulama inşası ekranlar veya koda başlamadan önce başlar: net bir problem, belirli bir kullanıcı ve sıkı bir ilk sürüme (MVP) ihtiyacınız var. Yapay zeka size daha hızlı düşünmede yardımcı olabilir—ama hangi şeylerin önemli olduğuna karar veren yine sizsiniz.

Eğer Koder.ai gibi bir vibe-coding aracı kullanıyorsanız, bu adım daha da önem kazanır. Kullanıcı, değer ve kapsam ne kadar net olursa, platform sohbet tabanlı planı temiz, incelenebilir ekranlara, API’lere ve veri modellerine dönüştürebilir.

Problemi ve kimin için olduğunu tanımlayın

Problemi özellikler olmadan, sade dilde anlatın.

• Kötü: “Sohbet, takvimler ve hatırlatıcıları olan bir uygulama istiyorum.”
• Daha iyi: “İnsanlar toplantılardan sonra önemli takipleri unutuyor; görevler aksıyor ve güven azalıyor.”

Şimdi ana kullanıcıyı adlandırın (tek bir grup). “Yoğun profesyoneller” çok geniştir; bunun yerine “3–10 aktif müşterisi olan freelance tasarımcılar” gibi daraltın. Bağlam ekleyin: nerede oldukları, bugün hangi araçları kullandıkları ve problemi tetikleyen durumlar.

Yapay zeka istemi: “Hedef kullanıcıyı ve tam problemi daraltmak için bana 10 soru sor. Sonra en iyi kullanıcı personasını 5 madde halinde özetle.”

Bir cümlelik değer önerisi yazın

Değer öneriniz yapışkan nota sığmalı:

“[kullanıcı] için, [uygulama] [işi] şu şekilde yapar: [benzersiz yaklaşım], böylece [ölçülebilir sonuç].”

Örnek: “Freelance tasarımcılar için, MeetingLoop toplantı notlarını öncelikli takiplere dönüştürür, böylece müşteri görevleri kaçmaz.”

3–5 temel kullanıcı işini listeleyin

Butonlara değil, sonuçlara odaklanın. Amacınız uygulamanın faydalı olduğunu kanıtlayacak en küçük iş setini belirlemek.

Tipik temel işler şunlar olabilir:

• Bilgiyi hızlıca yakalamak (anında)
• Bu bilgiyi net bir sonraki adıma dönüştürmek
• Bugün yapılacakları gözden geçirmek
• Doğru zamanda hatırlatmalar almak
• İlerlemenin bir başkasıyla paylaşılması (isteğe bağlı)

Yapay zeka istemi: “Kullanıcım ve değer önerim göz önünde bulundurularak 5 temel kullanıcı işi öner ve MVP için önem sırasına göre sırala.”

Başarı metriklerini belirleyin

MVP’nin işe yarayıp yaramadığını söyleyecek birkaç sayı seçin:

• İndirmeler/kurulumlar: İnsanlar merak ediyor mu?
• Aktivasyon: İlk ana eylemi (ör. ilk öğeyi oluşturma) 5 dakika içinde tamamlıyorlar mı?
• Tutma: 7 gün sonra geri dönüyorlar mı?

Metrikleri temel işlere bağlı tutun, gösteriş amaçlı sayılara değil.

MVP ile “sonra” özelliklerini ayırın

Basit bir kural: MVP, kullanıcıların ana işi en az bir kere uçtan uca tamamlamasını sağlamalıdır.

İki liste oluşturun:

• MVP: değeri kanıtlamak için olması gerekenler
• Sonra: hoş olur, karmaşık veya “iyi olurdu” olanlar

Emin değilseniz AI’ye sorun: “Vaadedilen sonucu hala sunan en basit sürüm nedir? Önce neyi kesmeliyim?”

Fikri İnşa Edilebilir Gereksinimlere Dönüştürün

Net bir gereksinimler kümesi, “harika bir uygulama fikri”ni takımınızın (veya siz+AI) gerçekten inşa edebileceği bir şeye dönüştürür. Amaç mükemmel bir spesifikasyon değil—ilk sürümün ne yapması gerektiğine dair paylaşılan, test edilebilir bir anlayıştır.

Bir persona ve bir ana yolculukla başlayın

Tek bir ana kullanıcı seçin ve kısa bir persona yazın:

• Kimdir? (rol, bağlam)
• Hangi problemi çözmeye çalışıyor?
• Uygulamayı kullanmaya karar verdiği an nedir?

Sonra ana yolculuğu uygulamayı açmaktan “değer elde etmeye” kadar 5–8 adım olarak yazın. Somut olun (dokun, seç, kaydet, öde, paylaş), muğlak ifadelerden kaçının (“etkileşim kur”, “katıl”).

AI’ye verebileceğiniz kullanıcı hikayeleri taslağı yazın

Her yolculuk adımını kullanıcı hikayelerine dönüştürün:

• Bir kullanıcı olarak, [bir şey yapmak istiyorum], böylece [fayda].

Örnek:

• Bir kullanıcı olarak Apple veya Google ile giriş yapmak istiyorum, böylece parola oluşturmadan hızlıca başlayabileyim.
• Bir kullanıcı olarak bir öğeyi favorilere kaydetmek istiyorum, böylece daha sonra bulabileyim.

Önceliklendirme: Olmazsa Olmaz / Olmalı / Olabilir

MVP belirliyorsunuz, bu yüzden acımasız olun:

• Olmazsa Olmaz (Must): olmadan uygulama çalışmaz (temel değer, yasal, ödeme gerekiyorsa)
• Olmalı (Should): önemli ama MVP sonrası eklenebilir
• Olabilir (Could): hoş, kolay kazanımlar, deneyler

Eğer iki “Olmazsa Olmaz” birbirine bağımlıysa, birleştirip uçtan uca teslim edilebilen tek bir dilime çevirin.

Kabul kriterlerini sade dilde ekleyin

Her Olmazsa Olmaz hikaye için herkesin doğrulayabileceği 3–6 kontrol yazın:

• “Çıkış yapmışken, ‘Google ile devam et’e dokunduğumda giriş yapıp Ana ekrana yönlendirilmeliyim.”
• “Ağ başarısız olursa, uygulama yeniden deneme mesajı göstermeli ve yazdıklarımı kaybetmemeli.”

Kaba çabayla gerçekçi tutun

Hafif boyutlandırma kullanın, kusursuzluk değil:

• S (1–2 gün), M (3–5 gün), L (1–2 hafta)

Eğer bir özellik L ise, MVP öğelerinin çoğu S/M olana kadar bölün. Bu, AI destekli uygulamayı daha güvenli kılar çünkü değişiklikler daha küçük ve gözden geçirilmesi kolay olur.

AI ile Kullanıcı Akışları ve Ekran Haritası Oluşturun

Piksellere tasarıma veya koda geçmeden önce uygulamada hangi ekranların olduğunu, insanların nasıl gezineceğini ve aksayan durumlarda ne olacağını netleştirmeniz gerekir. AI hızlı ilk taslak üretmede iyidir—ancak bunu bir eskiz olarak görün, son karar gibi değil.

AI’den ekranlar + navigasyon isteyin

Kısa bir ürün tanımı ve MVP hedefiyle başlayın, sonra ekran listesi ve navigasyon modeli (sekme, yığın, onboarding vb.) isteyin. İşe yarayan bir istem:

You are a product designer. Based on this MVP: <describe>, propose:
1) a list of screens (MVP only)
2) primary navigation (tabs/drawer/stack)
3) for each screen: purpose, key components, and CTA
Keep it to ~8–12 screens.

Tıklanabilir bir akış taslağı üretin

Bunu bir “ekran haritası”na çevirin: storyboard gibi gözden geçirebileceğiniz numaralandırılmış ekranlar ve geçişler.

İstediğiniz örnek çıktı:

• 1. Welcome → (Continue) → 2. Sign in
• 2. Sign in → (Success) → 4. Home; (Forgot password) → 3. Reset
• 4. Home → (Tap item) → 5. Details → (Buy) → 6. Checkout

Boş ve hata durumlarını dahil edin

Her ekran için veri olmadığında, ağ yavaş olduğunda, geçersiz girişte veya izin reddedildiğinde ne gösterileceğini AI’den isteyin. Bu durumlar genellikle gerçek gereksinimler doğurur (yükleme göstergeleri, yeniden dene eylemleri, çevrimdışı mesajlar).

Hızlı doğrulama için 3–5 röportaj yapın

Akış taslağını 3–5 hedef kullanıcıya götürün. Onlardan “bir görevi tamamlamalarını” isteyin (UI yok). Tereddüt ettikleri yerleri gözlemleyin ve eksik adımları ya da kafa karışıklıklarını not edin.

UI öncesi MVP akışını kilitleyin

Düzeltmelerden sonra MVP ekran haritasını dondurun. Bu, inşa kontrol listeniz olur—UI ve uygulamaya geçerken kapsam kaymasını önlemeye yardımcı olur.

AI ile Veri Modeli ve İş Kurallarını Tasarlayın

Temiz bir veri modeli, bir özelliği eklediğinizde uygulamanın parçalanmamasıyla, yoksa her eklemede kırılmayla arasındaki farktır. AI, özellik listenizi hızla varlıklara, ilişkilerine ve kurallara dönüştürebilir—ama bunun işleyişle gerçekten örtüştüğünden emin olmanız gerekir.

Temel varlıklarla başlayın (“isimleriniz”)

Uygulamanızın sakladığı ve referans verdiği ana şeyleri listeleyin: User, Project, Order, Message, Subscription vb. Emin değilseniz, MVP kapsamınızı tarayın ve her kullanıcı hikayesindeki isimleri vurgulayın.

Sonra AI’ye spesifik bir istekte bulunun:

“Bu MVP ve bu ekranlar göz önünde bulundurularak minimum varlık setini ve alanları öner. Birincil anahtarlar, zorunlu vs isteğe bağlı alanlar ve örnek kayıtlar dahil et.”

AI’den ilişkiler isteyin (ve meydan okuyun)

AI’den şu tür ilişkiler önermesini isteyin:

• Bir Kullanıcı → birden çok Proje
• Bir Proje → birden çok Görev
• Bir Sipariş → bir Ödeme (veya kısmi iadeler için birden çok)

Sonrasında uç durumlarla takip edin: “Bir Proje birden çok Sahibe sahip olabilir mi?”, “Bir Kullanıcı silinirse ne olur?”, “Denetim/geçmiş için yumuşak silme (soft delete) gerekli mi?” gibi.

İş kurallarını açıkça yazın

AI’den kuralları test edilebilir ifadeler hâlinde listelemesini isteyin:

• Doğrulama: “Sipariş toplamı, satır öğeleri toplamı eksi indirim artı vergidir.”
• Sınırlamalar: “Ücretsiz plan en fazla 3 aktif proje izin verir.”
• Fiyatlandırma: “İndirim kodu vergi öncesi uygulanır; yönlendirme kredileriyle birleştirilemez.”

Tek bir doğruluk kaynağı oluşturun

Kuralların yaşadığı ve güncellendiği tek bir yer seçin: repodaki kısa bir “Business Rules” dokümanı, bir şema dosyası veya paylaşılan bir spesifikasyon sayfası. Anahtar nokta tutarlılık—UI, backend ve testler aynı tanımlara başvurmalı.

Çevrimdışı vs çevrimiçi davranışı karar verin

İnternetsiz nelerin çalışması gerektiğini (önbelleğe alınmış projeleri görüntüleme, taslak siparişler, mesajları kuyruğa alma) netleştirin ve nelerin sunucu gerektirdiğini (ödeme, hesap değişiklikleri) belirtin. Bu karar veri modelinizi etkiler: yerel ID’ler, senkron durumları ve çakışma kuralları gerekebilir (ör. “son yazan kazanır” vs “alanları birleştir”).

Mobil Yığını ve Yüksek Seviye Mimariyi Seçin

Teknik seçimler ilk sürümü göndermeyi kolaylaştırmalı; her şeyi “geleceğe hazır” hâle getirmeye çalışmayın. MVP hedeflerinizi ve takımın yeteneklerini karşılayan en basit yığını seçin.

Uygulama türünü seçin (ve neden)

Native (Swift/Kotlin): en iyi performans ve platforma özgü incelik, ama iki kere inşa edersiniz.

Çapraz-platform (React Native veya Flutter): iOS + Android için tek kod tabanı, küçük takımlar için daha hızlı yineleme. MVP’ler için genelde iyi varsayılan.

PWA: içerik veya basit iş akışları için en ucuz yol, ama cihaz özelliklerine erişim ve uygulama mağazası görünürlüğü sınırlı.

Uygulamanız kamera, Bluetooth veya karmaşık animasyonlara çok bağımlıysa, native veya olgun çapraz-platform kurulumuna yönelin.

Yeni başlayanlara uygun, yaygın bir yığın

Birçok MVP için pratik seçenek:

• Mobil: React Native (Expo) veya Flutter
• Backend: Node.js (NestJS/Express) veya Python (FastAPI)
• Veritabanı: PostgreSQL
• Auth: yönetilen kimlik doğrulama (ör. Firebase/Auth0) veya backend’in JWT’si
• Barındırma: ops işini azaltmak için yönetilen platformlar (Render/Fly.io/Supabase/Firebase)

Daha “tek platform” bir yaklaşım isterseniz, Koder.ai sohbetten tam yığın uygulamalar üretebilir ve modern varsayılan yığınlarla iyi çalışır: web için React, backend servisleri için Go ve veri için PostgreSQL. Mobil için tek kod tabanı istiyorsanız Flutter güçlü bir tercihtir.

AI’den mimari diyagram (açıklama) isteyin

Mükemmel bir diyagrama ihtiyacınız yok—AI’nin üreteceği yazılı açıklama yeterlidir:

Describe a high-level architecture for a cross-platform mobile app:
- React Native client
- REST API backend
- PostgreSQL database
- Auth (email + OAuth)
- Push notifications
Include data flow for login, fetching list items, and creating an item.
Output as: components + arrows description.

Bu açıklamayı kod yazmadan önce herkesin aynı sayfada olduğundan emin olmak için kullanın.

Ortamları planlayın: dev → staging → production

Erken üç ortam kurun. Staging, üretimi aynalayan (aynı servisler, ayrı veri) olmalı ki sürümler güvenle test edilebilsin.

Risk azaltmak için önce neyi inşa edeceğinizi belirleyin

En zor parçaları kanıtlayan “ince dilimi” inşa edin:

• Kimlik doğrulama
• Bir ana iş akışı uçtan uca (oluştur/oku/güncelle)
• Temel hata yönetimi + loglama

Bunlar çalıştıktan sonra özellik eklemek tahmin edilebilir olur.

API’leri ve Entegrasyonları Planlayın (AI Destekli Spesifikasyon)

Ekranları inşa etmeden önce uygulamanın backend ve üçüncü taraf hizmetlerle nasıl konuşacağını kararlaştırın. Hafif bir API spesifikasyonu, mobil ve backend takımlarının özellikleri farklı yorumlamasını engeller.

Gerçekten ihtiyacınız olan entegrasyonlarla başlayın

MVP’nizin bağımlı olduğu dış servisleri ve gönderip aldığınız verileri listeleyin:

• Auth: e-posta/OTP, sosyal giriş veya “Apple/Google ile giriş”
• Ödemeler: Stripe/Adyen/Uygulama İçi Satın Almalar (hangi akışların gerektiğini netleştirin)
• Haritalar & konum: Google Maps/Mapbox, geocoding, mesafe hesapları
• Push bildirimleri: APNs/FCM, bildirim tipleri ve deep linkler
• Analitik/Kazalar: olay isimleri, gizlilik kısıtları

Planınızda veya destek seviyesinde emin değilseniz, paydaşları /pricing öğesine yönlendirin.

AI’yi uç noktalar ve yükler taslağı için kullanın

AI’ye özellik listenizi verin ve ilk taslak API sözleşmesini isteyin. İstem örneği:

“Kullanıcı kayıt/giriş, sipariş oluştur, siparişleri listele, sipariş durum güncelleme için bir REST API taslağı hazırla. İstek/yanıt JSON, kimlik doğrulama yöntemi, sayfalama ve idempotency ekle.”

REST (basit, öngörülebilir) veya GraphQL (esnek sorgular) için istekte bulunun. İsimlendirmede tutarlılık sağlayın.

Hataları ve uç durumları baştan tanımlayın

Hata formatınızı tüm uç noktalar için tutarlı yapın (mobil ekipler bunu sever):

{ "error": { "code": "PAYMENT_DECLINED", "message": "Card was declined", "details": {"retryable": true} } }

Ayrıca AI’nin atlayabileceği uç durumları dokümante edin:

• süresi dolmuş auth tokenları ve yenileme davranışı
• çevrimdışı mod (istekleri kuyruklamak mı? engellemek mi?)
• çift dokunuşlar (oluştur/charge için idempotency anahtarları)
• hız limitleri, yavaş ağ zaman aşımı ve kısmi hatalar

Spesifikasyonu bir sözleşme olarak görün

API sözleşmesini paylaşılan bir dokümanda (veya OpenAPI/Swagger olarak) yayınlayın. Versiyonlayın, değişiklikleri gözden geçirin ve “tamam” kriterleri üzerinde anlaşın (durum kodları, alanlar, zorunlu/isteğe bağlı). Bu, AI tarafından üretilen mantığın gerçek sistemle uyumlu kalmasını sağlar ve haftalarca sürebilecek yeniden çalışmayı engeller.

UI Tel Çizimleri (Wireframe) ve Basit Bir Tasarım Sistemi Oluşturun

Tel çerçeveler uygulamanızı kullanıcının ne yapması gerektiğine odaklar—görünüşe değil. Hızlı tel çerçeveleri küçük bir tasarım sistemiyle eşleştirdiğinizde, iOS ve Android’de tutarlı ve AI ile oluşturulması daha kolay bir UI elde edersiniz.

AI’den ekran başına bileşen listesi oluşturmasını isteyin

Ekran haritanızla başlayın, sonra AI’den her ekranı bir bileşen kontrol listesine dönüştürmesini isteyin. Bu, “güzel bir düzen” demekten daha uygulanabilirdir.

İstem örneği:

For the following screen: "Order Details"
- user goal:
- key actions:
- edge cases (empty, error, slow network):
Generate:
1) UI components (buttons, fields, lists, cards)
2) Component states (default, disabled, loading)
3) Validation rules and error copy
Return as a table.

Çıktıyı taslak olarak ele alın. Aradığınız şey tamamlayıcılıktır: hangi alanlar var, hangi eylemler birincil, hangi durumları tasarlamanız gerekiyor.

Küçük ama gerçek bir tasarım sistemi oluşturun

Tam bir tasarım kütüphanesine gerek yok. Farklı görünmelerini engelleyecek kadar az ama yeterli tanım yapın:

• Renkler: primary, background, surface, text, error, success
• Tipografi: 2–3 metin stili (başlık, metin, küçük yazı)
• Boşluk: bir ölçek seçin (ör. 4 / 8 / 16 / 24)
• Bileşenler: buton, metin alanı, kart, liste satırı, boş durum

AI’den marka tonunuza göre başlangıç değerleri önermesini isteyin, sonra okunabilirlik ve kontrast için ayarlayın.

Yeniden iş yapmayı azaltan erişilebilirlik temelleri

Bunları tel çerçevelere ve bileşen speslerine dahil edin:

• Kontrast: tüm yüzeylerde metin okunur olsun
• Dokunma hedefleri: rahat boyutlar ve boşluklar hedefleyin
• Net etiketler: yalnızca simge kullanmayın; metin veya erişilebilir etiket ekleyin

“Mutlu olmayan” yolları tasarlayın

Birçok MVP burada başarısız olur. Bu yolları açıkça tel çerçevelerde gösterin:

• Yükleme: iskelet mi yoksa spinner mı, hangi öğeler kullanılabilir kalır
• Çevrimdışı: önbelleğe alınmış içerik, yeniden dene butonları, net mesajlar
• İzinler: izin istemeden önce açıklama, reddedilmiş durum ve ayarlar bağlantısı

iOS ve Android’i tutarlı tutun (zorlamadan)

Yapı, metin ve bileşen kurallarını her yerde aynı tutun; platform geleneklerinin (navigasyon, sistem diyalogları) gösterilmesine izin verin. Amaç tutarlılık; aynı olmak zorunda değil.

Projeyi Kurun: Repo, CI ve İş Akışı

Gerçek mantık üretmeden önce, değişikliklerin izlenebilir ve sürümlerin öngörülebilir kalmasını sağlayacak bir temel kurun. Temiz bir iş akışı, AI destekli kodun izlenemez değişiklikler haline gelmesini engeller.

Repo kurulumu (yapı, dallanma, incelemeler)

Küçükse tek bir repo (mobil + backend), ekipler ayrıksa repo ayırın. Her durumda, uygulamayı çalıştırma, konfigürasyonların nerede olduğu ve nasıl yayınlanacağına dair kısa bir README yazın.

Basit bir dallanma modeli kullanın:

• main: her zaman yayınlanabilir
• özellik dalları: feat/login, fix/crash-on-start

Git barındırma ayarlarında kod inceleme kuralları koyun:

• En az 1 onay gereksinimi (ödeme/auth değişiklikleri için 2)
• CI başarısızsa merge engelle
• Küçük PR’ları tercih edin (idealde <300 satır değişiklik)

CI ile sorunları erken yakalayın

Her pull request’te CI çalışacak şekilde ayarlayın:

• Lint/format (hızlı geri bildirim)
• Birim testler (temel mantık)
• Derleme artefaktı (derlendiğini bilmek için)

Artefaktları kolay bulunur tutun (ör. debug APK/IPA’yı CI çalışmasına ekleyin). GitHub Actions kullanıyorsanız iş akışlarını .github/workflows/ içinde tutun ve açık adlar verin: ci.yml, release.yml.

AI iskeleti: güvenli kullanım, sonra inceleme

AI, boilerplate (ekranlar, navigasyon kabuğu, API istemcisi stub’ları) üretmede iyidir. Üretileni genç bir geliştirici katkısı gibi ele alın:

• Üretimi yeni bir dalda yapın
• Minimal, odaklı değişiklikler isteyin
• Birleştirmeden önce güvenlik, veri işleme ve hata durumlarını kontrol edin

Eğer Koder.ai kullanıyorsanız aynı disiplini uygulayın: Planning Mode ile kapsamı kilitleyin, sonra snapshot/rollback ile yanlış giden üretimleri geri alabilecek şekilde ilerleyin.

Görev panosu + “yapım tanımı”

Kullanıcı hikayeleriyle eşleştirilmiş bir görev panosu oluşturun (GitHub Projects/Jira/Trello). Her özellik için “yapım tanımı” şu olsun:

• Cihazda/emulatörde çalışıyor
• Ana mantık için testleri var
• Temel dokümantasyon içeriyor (ne yaptığı, nasıl doğrulanır)

Bu iş akışı AI tarafından üretilen mantığı güvenilir, izlenebilir ve yayınlanabilir kılar.

AI-Üretilmiş Mantığı (Güvenli) Kullanarak Özellikleri Uygulayın

AI, özellik teslimatını hızlandırır; ama onu genç bir ekip arkadaşı gibi değerlendirin: yardımcı taslaklar, nihai otorite değil. En güvenli yol, AI’yi başlangıç yapısı (ekranlar, navigasyon, saf fonksiyonlar) üretmek için kullanmak; sonra davranışı, uç durumları ve kaliteyi insanlar onaylasın.

Ekran + navigasyon başlangıç kodu üretin

“İnce” ekranlar isteyin: UI olaylarını açıkça adlandırılmış fonksiyonlara bağlayan, ağ kodu içermeyen ekranlar. Örnek: “Bir LoginScreen oluştur: e-posta/parola alanları, yükleme durumu, hata gösterimi ve başarı halinde Home’a navigasyon—henüz ağ kodu yok.” Bu, UI’yi okunaklı tutar ve parçaları daha sonra değiştirmeyi kolaylaştırır.

İş mantığını küçük, açık ve test edilebilir tutun

Kararları saf fonksiyonlara ittirin: fiyatlandırma kuralları, doğrulamalar, izinler ve durum geçişleri. AI, örnekler verdiğinizde bunları taslak hâline getirmede iyidir.

Kullanışlı bir istem şablonu:

• Girdi/çıktılar (tiplerle)
• Kurallar (“Abonelik süresi dolduysa, dışa aktarmayı engelle”)
• Uç durumlar (boş, null, zaman dilimleri, yeniden denemeler)
• 5–10 somut örnek (“X verildiğinde Y dönsün”)

Çıktı geldiğinde, belirsiz olan her şeyi daha küçük fonksiyonlara ayırın.

İstemleri ve çıktıları repoya kaydedin

/ai/feature-login/ gibi bir klasör ekleyin ve içine:

• prompt.md (ne sordunuz)
• output.md (aldığınız şey)
• Kabul edilen veya değiştirilen noktalar hakkında notlar

Bir hatayla karşılaşıldığında izlenebilirlik sağlar.

Güvenlik, doğruluk ve stil için inceleyin

AI yazılı kodu birleştirmeden önce kontrol edin: veri doğrulama, auth kontrolleri, gizli anahtar yönetimi (anahtarları gömme), hata mesajları (detay sızdırmasın) ve bağımlılık kullanımı. İsimlendirme ve biçimlendirmeyi takımınızın stiline uygun hale getirin.

Erken refaktör yapın

AI garip desenler (devasa dosyalar, tekrarlanan mantık, belirsiz durum) getirdiyse hemen düzeltin. Erken küçük temizlikler, sonradan zor değişiklikleri önler.

Test Stratejisi: Birim, Entegrasyon ve Cihaz QA

Testler, AI-üretimli mantığın güveninizi hak edip etmediğini gösterir. İyi bir strateji hızlı, otomatik kontroller (birim + entegrasyon) ile gerçek cihazlarda yapılan testleri karıştırır.

Birim testleri: kurallar, doğrulamalar ve uç durumlar

İş kurallarını birim testleriyle koruyun: doğrulamalar, hesaplamalar, izin kontrolleri, biçimlendirme ve API verisini UI’nin gösterdiği şeye çeviren mappingler.

AI’yi uç durumları genişletmek için kullanın, ama davranışı uydurmasına izin vermeyin. Kurallarınızı verin ve bu kuralları kanıtlayan testler isteyin.

• Parola kuralları, zorunlu alanlar, toplam/ücret hesaplamaları, tarih sınırları için birim testleri yazın.
• Hata modları için testler ekleyin (null/boş değerler, beklenmeyen enum’lar, çevrimdışı durumlar).

Entegrasyon testleri: API + auth akışları uçtan uca

Birim testleri bir arada çalışmayı garanti etmez. Entegrasyon testleri uygulamanın:

• Giriş / token yenileme / süresi dolmuş oturumları yönetmesini
• Gerçek veya mocked API uç noktalarını çağırmasını ve yanıtları çözümlemesini
• Yükleniyor, hata ve başarı için doğru UI durumlarını göstermesini

doğrular.

Kararlı testler için “test server” veya kaydedilmiş fixture’lar kullanın.

Cihaz QA: kullanıcıların gerçekten kullandığı ekranlar

Otomatik testler sağlam olsa bile cihaz QA insan tarafındaki sorunları yakalar: kesik metin, bozuk klavye davranışı, garip animasyonlar, izin istemleri.

• Temel ekran boyutlarında test edin (küçük telefon, büyük telefon; destekliyorsanız en az bir tablet).
• Eğer iOS ve Android yayınlıyorsanız her iki platformu da test edin—navigasyon ve izinler farklıdır.

AI destekli test vakaları (ne zaman şüpheci olunmalı)

AI’den kullanıcı hikayelerinizden test vakaları ve kontrol listeleri (mutlu yol + en sık 10 hata yolu) oluşturmasını isteyin. Sonra listeyi gerçek UI ve gereksinimlerle karşılaştırın—AI sıklıkla platforma özgü adımları atlar.

Yayın hazırlığı: stabilite ve performans

Göndermeden önce kullanıcıların en çok fark edeceği şeylere odaklanın:

• Çökme ve performans problemlerini düzeltin (soğuk açılış süresi, kaydırma takılmaları, API zaman aşımı)
• Her düzeltmeden sonra en önemli akışları tekrar test edin (giriş, onboarding, satın alma/ana eylem, çıkış)

Dağıtım: App Store/Play Store ve Backend Yayını

Dağıtım bir düğmeye basmaktan öte sürprizleri azaltmaktır. AI evrak ve kontrol listelerini hızlandırabilir, ama politika, gizlilik ve son derleme için insan onayı gereklidir.

Mağaza varlıklarını hazırlayın (AI destekli)

AI’den MVP kapsamınıza göre mağaza açıklaması taslağı isteyin: net bir kısa değer cümlesi, 3–5 ana özellik ve kısa “nasıl çalışır” bölümü. Sonra bunu kendi sesinizle yeniden yazın.

Hazırlayın veya son haline getirin:

• Uygulama ikonu (çeşitli boyutlar), Android için feature graphic ve yaygın cihaz boyutları için ekran görüntüleri
• Kısa tanıtım metni + tam açıklama
• Anahtar kelimeler (iOS) ve etiketler (Android)

AI ipucu: “faydaları anlatan beş ekran görüntüsü başlığı” isteyin, sonra her başlığı gerçek bir ekrana eşleyin.

İmzalama, sertifikalar ve sürüm derlemeleri

İmzalamayı erken ayarlayın ki yayın günü hesap sorunları engel olmasın.

• iOS: Sertifikalar, Identifiers, Profiller; App Store Connect erişimini doğrulayın
• Android: Keystore + Play Console uygulama kaydı; keystore yedeklerini saklayın

Release derlemelerini (debug olmayan) oluşturun ve test edin. İç test kanallarını (TestFlight / Play Internal Testing) kullanarak kurulum, giriş, push bildirimleri ve deep linkleri doğrulayın.

Yayın kontrol listesi (gizlilik, izinler, politikalar)

Göndermeden önce doğrulayın:

• Gizlilik politikası URL’si doğru ve gerçek veri toplamayla uyumlu
• İzinler uygulama içinde gerekçelendiriliyor (kamera, konum, kişiler vb.)
• İzleme/analitik açıklamaları doğru
• Hesap silme (gerekliyse) mevcut ve dokümante edilmiş

Backend yayını: önce staging

Backend’i staging’e dağıtın ve “sürüm adayı” kontrolünü çalıştırın: migration’lar, background job’lar, webhook’lar ve API hız limitleri. Ardından aynı artefakt/konfigürasyonu üretime taşıyın.

Kademeli dağıtım ve geri alma planı

Kademeli bir yayın planlayın (ör. %5 → %25 → %100) ve geri alma adımlarını tanımlayın:

• Mobil: yayını durdur, gerekirse mağaza sürümünü önceki hâline döndür
• Backend: feature flag’ler, versiyonlu API’ler, veri tabanı migration geri alma stratejisi

Eğer aracınız snapshot ve rollback destekliyorsa (ör. Koder.ai snapshot/rollback ve kaynak kodu dışa aktarma içerir), büyük sürümler öncesi bilinen iyi bir durumu dondurun.

AI’den yardım isterseniz, uygulamanızın izinleri, entegrasyonları ve kategoriye göre özel bir yayın kontrol listesi oluşturmasını isteyin—sonra her maddeyi manuel doğrulayın.

Yayından Sonra İzleyin, Öğrenin ve İterasyon Yapın

Yayın bitiş çizgisi değildir—kullanıcı verisini nihayet elde ettiğiniz andır. Amaç sık bir döngü kurmak: kullanıcıların ne yaptığını ölç, neden yaptıklarını öğren ve öngörülebilir bir tempoda iyileştir.

Aktivasyona bağlanan analitiği ekleyin

Yeni kullanıcının değere ulaşıp ulaşmadığını açıklayan küçük bir etkinlik setiyle başlayın.

Örnek: Kayıt Ol → Onboarding Tamamla → İlk Öğeyi Oluştur → Paylaş/Dışa Aktar → Ertesi Gün Geri Dön. Her adımı olay olarak takip edin; plan türü, cihaz OS’si ve edinme kanalı gibi temel özellikleri ekleyin.

Her şeyi izlemektense, birkaç önemli olayı izlemek daha iyidir—bunu gerçekten inceleme olasılığınız daha yüksektir.

Çökme raporlaması ve uyarılar ekleyin

Analitik kullanıcıların ne yapmaya çalıştığını gösterir; çökme raporları neyin kırıldığını söyler. Çökme raporlarında:

• Sürüm ve derleme numarası
• Cihaz/OS dağılımı
• Çökmesiz oturum oranı belirli bir eşiğin altına düştüğünde uyarılar

Uyarıları takımınızın izlediği bir kanala yönlendirin (e-posta, Slack vb.) ve “hafif nöbet” kuralı belirleyin: kim bakar, ne sıklıkla ve ne acil sayılır.

Geri bildirimi kolay yere toplayın

Sadece mağaza yorumlarına güvenmeyin. Hafif bir geri bildirim yolu ekleyin:

• Ayarlar’da “Geri bildirim gönder” seçeneği
• Anlamlı bir dönümden sonra kısa bir uygulama içi istem (ilk açılışta değil)
• Uygulama sürümü ve cihaz bilgisini otomatik ekleyen destek e-posta formu

Geri bildirimi AI ile özetleyin

Bir iki haftalık yorum geldikten sonra AI’den geri bildirimleri temalara, sıklığa ve ciddiyete göre kümelemesini isteyin. İsteyebileceğiniz çıktılar:

• En çok görülen 5 kullanıcı sorunu (örnek alıntılarla)
• “Hızlı kazanımlar” vs “daha büyük yatırım gerektirenler”
• Karışık ekranlar için önerilen metin değişiklikleri

Özetleri her zaman bağlam için insan tarafından gözden geçirin—AI yardımcı bir analist, ürün sahibi değil.

Sonraki iterasyon yol haritasını planlayın

Düzenli güncelleme ritmi belirleyin (ör. haftalık hata düzeltmeleri, aylık özellik sürümleri). Kısa bir yol haritası şu karışımı içersin:

• Güvenilirlik (çökme, performans)
• Aktivasyon iyileştirmeleri (sürtünmeyi azalt)
• Her döngüde bir kullanıcıya görünür geliştirme

Eğer kamuya açık inşa ediyorsanız, kullanıcılarla döngüyü kapatmayı düşünün: Koder.ai gibi platformlar içerik üreterek kredi kazanma programları ve yönlendirmeleri destekleyebilir—bunlar büyürken yinelemeyi finanse etmeye yardımcı olabilir.

Eğer bu döngüyü düzenleyecek bir şablon isterseniz, takımınızı /blog/app-iteration-checklist sayfasına yönlendirin.