Anılog'u Nasıl Geliştirdim: Fikirden Mağazaya Bir Uygulamanın Karar Günlüğü

Bir uygulamayı geliştirmenin zor kısmı kod yazmak değil. Zor kısmı, hangi kodu yazmayacağına karar vermek. Anılog — arkadaş grubunun gün içinde belirlediği saatlerde birkaç saniyelik klip çektiği, gün sonunda hepsinin tek bir vloga dönüştüğü bir uygulama — bunun iyi bir örneği oldu.

Bu yazıda kodun kendisinden çok kararları anlatıyorum: neyi neden seçtim, hangi seçim beni sonradan ısırdı, hangisi tuttu.

Rakamlarla ne çıktı:

• 39 Dart dosyası, yaklaşık 7.400 satır
• 15 PHP dosyası, yaklaşık 2.000 satır — tamamı framework'süz, composer'sız
• MySQL tarafında 8 tablo
• iOS ve Android; her ikisinde de ana ekran widget'ı

Karar 1: Firebase'i sadece kimlik için kullanmak

İlk ve en belirleyici karar buydu. Firebase'in tamamını kullanmak (Auth + Firestore + Storage) en hızlı yol olurdu. Kullanmadım.

Sebep depolama maliyeti. Anılog video uygulaması: her kullanıcı her gün birkaç klip yüklüyor. Firebase Storage'da bu, kullanıcı sayısıyla doğru orantılı ve tahmin edilemeyen bir fatura demek. Zaten bir Hostinger paketim vardı; disk ve trafik oradaydı, üstelik sabit fiyatlıydı.

Sonuçta sınır şöyle çizildi:

• Firebase Auth → Google ve Apple ile giriş. Kimliğin doğruluğu Google'ın işi; ben o işi yeniden yazmam.
• Kendi PHP + MySQL sunucum → gruplar, klipler, yorumlar, tepkiler, medya dosyaları. Yani veri ve maliyetin hepsi.

Bu ayrımın bedeli, sunucunun Firebase'in verdiği kimlik jetonunu kendi başına doğrulaması gerektiği oldu. Bunu composer olmadan saf PHP'yle nasıl yaptığımı ayrı bir yazıda anlattım: Firebase Auth + kendi PHP sunucun.

Karar 2: Sosyal medya yapmamak

Anılog'un ilk taslağında keşfet akışı, herkese açık profil ve takip sistemi vardı. Hepsini sildim.

Sebep sadece sadelik değildi. Herkese açık içerik demek:

• İçerik moderasyonu demek. Bildirme, engelleme, inceleme kuyruğu.
• App Store 1.2 maddesi demek. Kullanıcı içeriği barındıran uygulamalarda bildirme ve engelleme mekanizması zorunlu.
• Ölçeklenmeyen bir depolama faturası demek.

Kapalı gruplar (en fazla 10 kişi, davet kodu ile) bunların hepsini ortadan kaldırıyor. Üstelik ürünün kendisini de iyileştiriyor: takipçi sayısı olmayan bir yerde insanlar gerçekten günlük hayatlarını paylaşıyor.

Ders: özellik silmek özellik eklemekten daha çok zaman kazandırıyor.

Karar 3: Çekim penceresi — ürünün kalbi

Herkesin istediği zaman klip çekebildiği bir uygulama, sıradan bir galeri. Ortak anı yaratan şey kısıt.

Model şu: grup birkaç çekim saati belirliyor (en fazla 8). Her saatten sonra bir pencere açılıyor; pencere kapanınca o öğün kapanıyor. Pencere süresini de grup seçiyor — 10 dakika, 30 dakika, 1 saat ya da 2 saat. Varsayılan 30 dakika.

Bu mantığı sunucuya yazdım, istemciye değil. İstemcideki saat kullanıcının kontrolünde; telefonun saatini değiştiren biri pencereyi istediği gibi açabilirdi. Sunucu tarafında yazdıktan sonra, gece yarısı devri ve yükleme payı dahil 13 senaryoyu yerel olarak test ettim. Gece yarısını geçen bir pencere (23:50 + 30 dk) ilk sürümde yanlış güne yazıyordu; testler olmasa fark etmezdim.

Karar 4: Kullanıcıyı hiçbir şeye zorlamamak

İlk kamera ekranımda telefonu yatay tutmaya zorluyordum. Video yatay olsun diye. Kendi uygulamamı kullanırken bundan nefret ettim ve söktüm.

Nihai davranış: arayüz dikey sabit, ama kamera serbest. İsteyen dikey çeker, isteyen yatay. Vlog birleştirme tarafı ikisini de kabul ediyor (nasıl olduğu ffmpeg yazısında).

Aynı ilke deklanşöre de uygulandı: tek dokunuş da çekiyor, basılı tutmak da. Basılı tutarken parmağı yukarı kaydırmak yakınlaştırıyor, çift dokunuş kamerayı çeviriyor — kayıt sürerken bile. Kullanıcının nasıl tutacağını tahmin etmek yerine her ihtimali destekledim. Kamera tarafındaki teknik ayrıntılar ayrı yazıda.

Karar 5: Vlog'u sunucuda değil telefonda üretmek

Gün sonunda klipleri birleştirip tek video yapmak sunucuda ffmpeg çalıştırmayı gerektirir. Paylaşımlı hostingte bu ya imkânsız ya da çok yavaş.

Vlog üretimini telefona taşıdım. Kazançları saydığımda kararın doğru olduğunu gördüm:

• Sunucuda CPU maliyeti yok
• Vlog dosyası hiç yüklenmiyor → depolama ve trafik yok
• Kullanıcının cihazından çıkmayan bir çıktı → gizlilik anlatısı dürüst

Bedeli: telefonda birkaç dakikalık işlem süresi ve platform başına ayrı ffmpeg testi. Kabul edilebilir bir bedel.

İsim nasıl seçildi

Sıkıcı ama pratik bir adım: isim, mağazada boş olmalı. Play Store ve App Store'da aday isimleri tek tek arattım. "Anılog" hem Türkçe anı kelimesini hem de log (kayıt) kelimesini taşıdığı, hem de aranınca başka bir şey çıkmadığı için kaldı.

Alan adı ve paket adı da aynı anda kontrol edildi: com.anilog. İsmi kod yazmaya başlamadan önce kilitlemek, sonradan paket adı değiştirmenin acısını yaşamamak demek. Bir kez yaşarsanız bir daha unutmuyorsunuz.

Yapay zekâ bu işin neresinde?

Anılog büyük ölçüde yapay zekâ destekli yazıldı — vibe coding yöntemiyle. Ama yukarıdaki beş kararın hiçbirini model vermedi. Model şunlarda hızlandırdı:

• Ekranların ilk hâlini kurmak
• ffmpeg filtre zincirini denemek (ve denemeleri gerçek dosyalarla ölçmek)
• PHP endpoint'lerini yazmak
• Aynı ekranı üç dile çevirmek

Şunlarda hiç yardımcı olmadı, çünkü olamaz:

• Hangi özelliğin silineceğine karar vermek
• Kullanıcının telefonu nasıl tuttuğunu tahmin etmek
• Maliyetin nerede patlayacağını görmek

Bu ayrım netleştiğinde yapay zekâ gerçekten hızlandırıcı oluyor. Netleşmediğinde, makul görünen ama tutarsız bir yığın kod üretiyor.

Şu an nerede

Anılog mağaza başvurusuna hazırlanıyor. Gizlilik politikası ve web üzerinden hesap silme akışı yayında, gizlilik bildirimi (PrivacyInfo.xcprivacy) ve şifreleme beyanı tamam.

Geriye dönüp baktığımda en değerli alışkanlık, her sayısal kararı tek bir yerde tutmak oldu: klip uzunluğu, grup sınırı, düzenleme süresi, pencere süresi. Hepsi sunucuda tek bir ayar dosyasında. Uygulama, sunucu ve tanıtım sayfası aynı sayıyı söylüyor — çünkü aynı yerden okuyorlar.

Serinin diğer yazıları:

• Flutter'da kamerayı kullanıcıya bırakmak
• Firebase Auth + kendi PHP sunucun
• ffmpeg ile telefonda video birleştirme