Sıfırdan 3 Ayda App Store ve Google Play: Hansel & Gretel Vaka Çalışması
Bir uygulama fikrini üç ayda iki mağazada canlıya çıkarmak: Hansel & Gretel için mobil uygulamayı, iki dilli web sitesini, sıfırdan tasarlanan API'yi ve hosting altyapısını tek elden kurduk. Kapsamı, teknik kararları ve sonucu anlatıyoruz.
Bir mobil uygulama fikrini mağazada yayınlanmış, gerçek kullanıcıların kullandığı bir ürüne dönüştürmek tek bir işten ibaret değildir: uygulamanın kendisi, onu besleyen arka uç, ürünü anlatan web sitesi ve hepsini ayakta tutan sunucu altyapısı aynı anda kurulmak zorundadır. Bu dört cepheyi ayrı ekiplere böldüğünüzde proje takvimi entegrasyon toplantılarında erir.
Hansel & Gretel projesinde bunları tek elden üstlendik. Sonuç: sıfırdan başlayan bir fikir, üç ay içinde hem App Store'da hem Google Play'de yayında.
Proje künyesi
| Müşteri | Hansel & Gretel (hanselandgretel.net) |
|---|---|
| Kapsam | Mobil uygulama (iOS + Android), web sitesi, özel API, hosting altyapısı |
| Başlangıç noktası | Sıfır — hazır bir kod tabanı, API veya altyapı yoktu |
| Süre | 3 ay |
| Çıktı | App Store ve Google Play'de yayınlanmış uygulama, iki dilli web sitesi, canlı API |
Ürün ne yapıyor?
Hansel & Gretel, yürüyüş, koşu, bisiklet ve şehir içi gezintiler için bir GPS rota takipçisi. Uygulama rotanızı canlı kaydediyor, kaydettiği izi ters yönde oynatarak sizi başladığınız noktaya geri götürebiliyor — üstelik bunu şebeke sinyali olmadan, çevrimdışı yapıyor. Kaydedilen rotalar isteğe bağlı olarak sosyal bir akışta paylaşılabiliyor ve diğer kullanıcılar tarafından keşfedilebiliyor.
Uygulamanın adı da bu davranıştan geliyor: masaldaki ekmek kırıntısı izini bırakma fikri, teknik olarak "kaydedilen yolu geri izleme" özelliğinin ta kendisi. Ürün ücretsiz ve reklamsız; konum verisi varsayılan olarak özel.
Zorluk: dört cephe, tek takvim
Bu tip bir üründe mobil uygulama tek başına bir işe yaramaz. Rota kaydı, fotoğraflar, kullanıcı hesapları ve sosyal akış bir yerde durmak zorunda; web sitesinin de aynı veriyi göstermesi gerekiyor. Klasik yaklaşımda önce uygulama yapılır, sonra "bir de API lazımmış" denir ve arka uç uygulamanın ekranlarına göre şekillenir. O noktadan sonra web tarafı ya ikinci bir arka uçla çözülür ya da hiç çözülmez.
Biz ters yönden başladık.
Çözüm: önce API, sonra istemciler
İlk kurduğumuz şey mobil uygulama değil, sıfırdan tasarladığımız API oldu. Bu API bugün hem mobil uygulamanın hem de web sitesinin tek veri kaynağı. Temel tasarım kararları:
- Tek doğruluk kaynağı. Rota, fotoğraf, kullanıcı ve sosyal akış verisi tek bir yerde tutuluyor. Mobil tarafta yapılan bir değişiklik web tarafında da geçerli; iki ayrı iş mantığını senkron tutma derdi hiç doğmadı.
- Token tabanlı kimlik doğrulama. Mobil istemci ile sunucu arasındaki her istek JWT ile doğrulanıyor. Oturum yönetimi sunucuda durum tutmadığı için uygulama çevrimdışıyken de tutarlı davranıyor.
- Yetki sınırları en baştan. Konum verisi hassas bir veri türü. Rotanın herkese açık mı özel mi olduğu, kullanıcı engelleme ve içerik bildirme akışları API'nin ilk sürümünde vardı — sonradan eklenen bir yama değil.
- Sürümlenebilir uç noktalar. Mağazadaki bir uygulamayı herkes aynı anda güncellemez. API, eski sürümdeki bir kullanıcının uygulaması çalışmaya devam edecek şekilde kurgulandı.
Çevrimdışı geri dönüş özelliği de bu tasarımın bir sonucu: rota verisi cihazda kaydedildiği ve navigasyon hesabı cihazda yapıldığı için, kullanıcı sinyalin çekmediği bir vadide de yolunu bulabiliyor. Sunucu senkronizasyonu sinyal geri geldiğinde devreye giriyor.
Web: pazarlama sayfası değil, ürünün ikinci yüzü
Web sitesi tarafında iki hedef vardı: uygulamayı anlatmak ve kullanıcıların paylaştığı rotaları arama motorlarına açmak. Her paylaşılan rota, web'de kendi adresi olan bir sayfaya dönüşüyor — mesafesi, süresi, rakım profili ve konumuyla. Bu, uygulamanın içindeki içeriğin aynı zamanda sitenin organik trafik kaynağı olması anlamına geliyor.
Site tamamen iki dilli kuruldu (İngilizce ve Türkçe), her iki tarafta da aynı yapı ve aynı içerik derinliğiyle. Yapay zeka destekli arama motorlarının ürünü doğru anlaması için siteye bir llms.txt dosyası da eklendi; ürünün ne olduğu, hangi platformlarda bulunduğu ve rota sayfalarının editöryel değil kullanıcı üretimi gerçek GPS kayıtları olduğu orada açıkça yazıyor.
Altyapı: uygulamayla birlikte kurulan sunucu
API, web sitesi ve blog aynı sunucu altyapısında, birbirinden ayrı alt alanlar üzerinde çalışıyor. Hosting tarafını da biz kurduğumuz için, uygulama geliştirme sırasında ortaya çıkan altyapı ihtiyaçları (SSL sertifikaları, PHP sürümü, dosya yükleme sınırları, arka plan görevleri) ayrı bir tedarikçiyle yazışmadan aynı gün çözüldü. Bir mobil uygulama projesinde bu, göründüğünden çok daha fazla zaman kazandırıyor.
Sonuç
Proje planlanan kapsamıyla üç ayda teslim edildi ve uygulama iki mağazada da yayına alındı:
Sıfırdan başlayan bir fikrin üç ay içinde iki büyük mağazada canlıya çıkması tek bir şeyin sonucu değil; API'nin uygulamadan önce tasarlanmasının, web ve mobilin aynı veri kaynağını paylaşmasının ve altyapının proje ekibinin elinde olmasının toplam etkisi.
Bu projeden çıkardığımız üç ders
- Arka uç, uygulamadan önce gelir. API'yi ekranlara göre şekillendirirseniz ikinci istemciyi (web, tablet, iş ortağı entegrasyonu) eklemek yeni bir proje olur.
- Kullanıcı üretimi içerik bir pazarlama varlığıdır. Uygulamanın içinde kalan veri sadece kullanıcıya hizmet eder; web'e açılan veri aynı zamanda yeni kullanıcı getirir.
- Tek elden teslim takvimi kısaltır. Mobil, web, API ve sunucunun dört ayrı muhataba dağıldığı projelerde geçen sürenin önemli bir kısmı geliştirmeye değil koordinasyona gidiyor.
Benzer bir projeniz mi var?
Bir uygulama fikriniz varsa ve bunu mobil, web ve altyapısıyla birlikte hayata geçirmek istiyorsanız, süreci nasıl kurguladığımızı konuşabiliriz. Yazılım geliştirme hizmetimizi inceleyebilir, web tasarım ve hosting tarafında neler yaptığımıza bakabilir ya da diğer referanslarımızı görebilirsiniz.