Seyahat giderlerini paylaşan bir mobil uygulamayı planlama, tasarlama ve inşa etme: temel özellikler, veri modeli, çoklu para birimi, çevrimdışı mod, ödemeler, test ve lansman.
Ekran tasarlamaya veya teknolojiyi tartışmaya başlamadan önce, uygulamanın kimlere hizmet ettiğini ve hangi anları iyileştirmesi gerektiğini acımasızca netleştirin. Gider bölüşmek “basit” görünür; ta ki gerçek bir gezi karışık para birimleri, yarı ödenmiş akşam yemekleri ve kaybolan bir fiş ekleyene kadar.
Çoğu seyahat gider paylaşım uygulaması birkaç tekrarlanabilir kullanıcı grubuna hitap eder. Önce bir ana grup seçin (sonra genişletebilirsiniz):
Her grubun beklentileri farklıdır. Arkadaşlar hız ve hafif bir ton isteyebilir; ekipler denetlenebilirlik, izinler ve dışa aktarım-ready kayıtlar talep edebilir.
Kullanıcıların şikâyet ettiği en karmaşık durumları belgeleyin:
Bunları 5–10 röportaj gibi gerçek insanlarla test edebileceğiniz senaryolara dönüştürün.
İlk sürümünüz için ölçülebilir hedefler koyun:
Bu yazı fikir ve MVP tanımından kenar durumlara, UX akışlarına, izinlere, veri mantığına ve son olarak test ve lansmana kadar pratik, uçtan uca bir yol haritasıdır. Doğru kullanıcılar ve sorunlarla başlarsanız, sonraki her karar kolaylaşır.
Seyahat gider paylaşım uygulaması için bir MVP “daha küçük bir uygulama” değil; kullanıcının seyahatteki tek işini güvenilir şekilde yapan bir versiyonudur: ortak harcamaları yakalamak ve kimin ne kadar borçlu olduğunu gösterip tartışma çıkarmamak.
Kapsamı sıkı ve sonuç odaklı tutun. Güçlü bir ilk sürüm sadece şu yeteneklerle başarılı olabilir:
Bu beş işi sorunsuz yapabiliyorsanız, kullanıcıların bir geziyi bitirebileceği bir gider bölüşme uygulamanız var demektir.
Birçok özellik “zorunlu” gibi görünür fakat çekirdek akışı doğrulana kadar bekleyebilir:
MVP hız ve açıklığı tamamlıktan önce tutmalıdır.
Hikâyeleri herkesin değerlendirebileceği günlük dille yazın:
Her hikâye için somut kontroller tanımlayın. “Yemeği böl” için örnek:
Bu, kapsam kaymasını önlerken insanların güveneceği bir seyahat gider uygulaması inşa etmenizi sağlar.
Bir seyahat gider paylaşım uygulaması, grubun harcamayı hızlıca yakalamasını ve matematiğe güvenmesini sağladığında başarılı olur. “Güzel özellikler” eklemeden önce, çekirdek özellik setinin gerçek gezilerde nasıl çalıştığını karşıladığından emin olun: birden çok kişi, birçok küçük harcama ve sıkça “sonra hallederiz” anları.
Kullanıcılar birden çok gezi oluşturabilmeli (örn. “Lizbon 2026”) ve basit bir link ya da kod ile başkalarını davet edebilmeli. Katılan biri üye olur ve giderlere eklenebilir.
Üye yönetimini hafif tutun: isim değiştir, erken ayrılanı çıkar, istersen roller (admin vs üye) ekleyin.
Her gider, haftalar sonra bile faydalı kalacak kadar yapı içermeli:
Hızlı giriş, mükemmel veriden daha önemlidir. Akıllı varsayılanlar (son ödeyen, son katılımcılar) dokunma sayısını azaltır.
Eşit bölüşme varsayılan olmalı, ancak esneklik sunun:
Uygulama her zaman “kim kime ne kadar borçlu?” sorusuna cevap vermeli. Kişi başı toplamlar, gezi toplamı ve borçların otomatik olarak netlendiği net bakiye görünümü sunun (ki kullanıcılar çok küçük transferler için peşinde koşmasın).
Kullanıcıların geri ödemeleri kaydetmesine izin verin: ödemeyi işaretle, tutarı/tarihi sakla ve isteğe bağlı yöntem (nakit, banka transferi, PayPal) belirtme. Güvence için kanıt eklemeye (ekran görüntüsü veya not) izin verin ama opsiyonel tutun; böylece kapatma hızlı olur.
Çoklu para birimi, gider bölüşme uygulamalarında sihirli ya da tartışma çıkaran noktalardan biridir. Her sayının hangi para birimini temsil ettiğini ve nasıl dönüştürüldüğünü açık tutarak çoğu “ben daha fazlasını ödedim” anını önleyebilirsiniz.
Her gideri bir işlem para birimi (mağazada gerçekte ödenen) ve bir gezi ana para birimi (grubun toplamları karşılaştırdığı) olarak ele alın.
Örneğin: bir akşam yemeği €60 (işlem), ama gezi ana para birimi USD ise uygulama €60 → $65.40 (dönüştürülmüş) gösterirken orijinal €60’ı şeffaflık için saklar.
İki iyi seçenek genelde şöyle:
Hangi yolu seçerseniz seçin, gider detaylarında kur ve zaman damgasını gösterin (örn. “1 EUR = 1.09 USD • 2025-12-26”). Düzenlemeleri destekliyorsanız, kullanıcıların gider bazında kur kilitlemesine izin verin.
Yuvarlama bir detay değil—politika meselesidir. Tutarlı kurallar kullanın:
Destekleyin:
Bunları ya ayrı kalemler olarak modelleyin (en açıklayıcı yöntem) ya da giderle ilişkilendirilmiş ayarlamalar olarak. Böylece sadece bazı kişilerin bahşişe katılması veya indirimin belirli öğelere uygulanması kolay olur.
Bir seyahat gider uygulaması hızıyla kazanır veya kaybeder. İnsanlar takside, kuyrukta veya gürültülü restoranlarda maliyetleri kaydeder—akışınız bir not almak gibi hissettirmeli, form doldurmak gibi değil.
Kullanıcıların bir gezide öğrenebileceği küçük ekran setiyle başlayın:
“Gider ekle” ekranını akıllı varsayılanlar etrafında tasarlayın:
İyi bir kural: kullanıcı sık kullanılan bir gideri 10–15 saniyede kaydedebilmeli.
Belirsiz etiketlerden kaçının. “Paid by” yerine “Ödeyen” ve “Owed by” yerine “Borçlu” gibi net terimler hata oranını düşürür. Kaydetmeden önce kompakt bir onay satırı gösterin: tutar, ödeyen ve kimlerin dahil olduğu.
Eğer sıra dışı görünüyorsa (örn. sadece bir kişi borçlu), nazikçe sorun: “Sadece Alex ile mi bölüştürülsün?”
Gezi detayları hızlı kontrolleri desteklemeli: filtreler (kişi, kategori, tarih) ve kişi bazlı görünüm. Bir etkinlik akışı (activity feed) güven oluşturur, özellikle düzenlemeler yapıldığında.
Okunabilir kontrast, büyük dokunma hedefleri ve açık çevrimdışı göstergeler (“Cihazda kaydedildi—sonra senkronize edilecek”) kullanın. Seyahat koşulları öngörülemez; UI buna göre dayanıklı olmalı.
Bir seyahat gider paylaşım uygulamasının ömrü, grubun aynı geziye ne kadar hızlı girebildiğine bağlıdır. Hesap ve davet kararlarınız sürtünmeyi azaltmalı.
MVP için genelde en basit ama güven veren seçenek istenir:
Pratik bir uzlaşma: Apple/Google + sihirli link. Hesap istemeyenler davetle katılabilir; düzenli kullanıcılar sonra gerçek bir oturum bağlayabilir.
İlk olarak paylaşılabilir bir davet linki sunun; kişi doğrudan geziye katılabilsin. Yüz yüze anlar için QR kodu ekleyin (tren platformu, hostel check-in). Kişi listesinden davet etme hoş ama izin talepleri ve kenar durumlar ekler—erken aşamada sıklıkla değmez.
Davetleri zaman sınırlı yapın:
Gruplarda bazıları uygulama yüklemeyecek veya oturum açmayacaktır. Destekleyip desteklemeyeceğinize baştan karar verin:
Yaygın bir MVP kuralı: misafirler yalnızca davet linki üzerinden görüntüleyip gider ekleyebilir, ancak silme veya gezi ayarlarını değiştirme gibi yetkiler yoktur.
Kim neyi düzenleyebilir açık olmalı:
Bu, kasıtlı veya kazara değişiklikleri önlerken akışı hızlı tutar.
Gerçek gruplar hızlı hareket eder. Düzenlemeleri öngörülebilir yapın:
Amaç mükemmel versiyon kontrolü değil—tartışmaları önlemek ve gezinin akmasını sağlamak.
Temiz bir veri modeli uygulamanızı öngörülebilir kılar: her ekran, hesaplama, dışa aktarma ve senkronizasyon buna bağlıdır. Onlarca tabloya gerek yok—doğru yapı taşları ve açık kurallar yeter.
Pratik olarak genelde şunlar gerekir:
Düzenlemeler birçok uygulamayı karıştırır. İki yaklaşım:
Orta yol: düzenlemeye izin verin ama para etkileyen alanlar için hafif bir geçmiş tutun.
Bakiye hesaplaması:
Sonra yerleşimler için netleme yaparak borçluları alacaklılarla eşleştirip minimum transfer sayısını üretin.
Gezi üyeleri: Alex (A), Blair (B), Casey (C). Tüm bölüşmeler dahil olanlar arasında eşit.
Akşam yemeği $60, A ödedi (A,B,C) → kişi başı $20
Taksi $30, B ödedi (B,C) → kişi başı $15
Müze $45, C ödedi (A,C) → kişi başı $22.50
Market $90, A ödedi (A,B,C) → kişi başı $30
Net sonuçlar:
Yerleşimler (netlenmiş): B → A $35.00, C → A $42.50.
Fişleri Expense'e bağlı ekler olarak ele alın: bir image URL/object key, küçük önizleme, uploaded_by, created_at ve opsiyonel OCR meta verisi (mağaza, algılanan toplam, güven).
Gideri resim yüklenirken veya çevrimdışıyken kullanılabilir kılmak için ek kaydını ana gider alanlarından ayırın.
Teknoloji seçimleriniz, inşa etmek istediğiniz ürüne hizmet etmeli: hareket halindeyken hızlı, spotty bağlantıda çalışabilen ve herkesin bakiyesini tutarlı tutan bir paylaşılan gezi cüzdanı.
Hızlıca spec'ten çalışır bir uygulamaya geçmek istiyorsanız, planlama ve uygulamayı kısaltan araçlar yardımcı olabilir. Örneğin, Koder.ai gibi platformlarda akışları sohbetle tanımlayıp (geziler, giderler, bakiyeler, settle-up) bir uygulama yığını (React web, Go + PostgreSQL backend, Flutter mobil) üretebilirsiniz. Bu ürün kararlarının yerine geçmez ancak MVP'ye ulaşma süresini kısaltabilir ve güvenli yineleme için snapshot/rollback sunabilir.
En sorunsuz kamera, çevrimdışı depolama ve OS entegrasyonları için native iOS (Swift) ve Android (Kotlin) ideal—ancak iki kod tabanı maliyeti vardır.
Çoğu ekip için çapraz-platform (Flutter veya React Native) pratik bir orta yol: tek bir UI katmanı, hızlı yineleme ve iyi performans.
Web-öncelikli (responsive web app) hızla doğrulama sağlar ama çevrimdışı ve fiş yakalama genelde daha az pürüzsüz hissedilir.
Basit bir gezi cüzdanı bile backend'ten faydalanır:
Çevrimdışı takip bir eklenti değil. Yerel veritabanı (SQLite/Realm) kullanın ve şu tasarımları uygulayın:
Endpointleri basit ve tahmin edilebilir tutun:
/trips, /trips/{id}/members/trips/{id}/expenses/trips/{id}/balances/trips/{id}/settlementsBu yapı gider bölüşme algoritması ve gelecekteki özelliklerle (ödeme linkleri, çoklu para birimi takibi) uyumlu.
Mobile App (UI)
-\u003e Local DB + Sync Queue
-\u003e API Client
-\u003e Backend (Auth, Trips, Expenses, Balances)
-\u003e Database
-\u003e File Storage (receipts)
-\u003e Notifications
Bu diyagramı geliştirme sırasında görünür tutun—“hızlı düzeltmeler”in MVP'yi karmaşıklaştırmasını önler.
Fişler “doğru olduğunu düşünüyoruz”dan “biliyoruz”a geçmeyi sağlar. Özellikle nakit ödemeler, ortak kart kullanımı veya farklı para birimleri olduğunda tartışmaları azaltır.
Fiş eklemeyi gider eklemenin bir parçası gibi hissettirin: kamera aç → çek → hızlı kırp/döndür → giderle ilişkilendir. Akış basit olmalı.
Birkaç pratik detay:
OCR faydalı ancak güvenilir olmalı. Toplam tutar ve satıcı gibi alanları öneri olarak çıkarın; kaydetmeden önce hızlı kullanıcı onayı isteyin.
İyi bir desen: çıkarılan değerleri düzenlenebilir chipler olarak gösterin (örn. “Toplam: 42.80”, “Satıcı: Café Rio”) ve kullanıcıların düzeltmesine izin verin. OCR başarısız olsa bile kullanıcı birkaç saniyede kaydı tamamlayabilmeli.
Tarih/saat cihazdan otomatik alınsın ve mümkünse konum (şehir veya mekan) önerilsin. Her zaman düzenlemeye izin verin—insanlar gideri sonra kaydedebilir.
Aşağıdaki durumlar için bildirim kullanın:
Fişler telefon numarası, sadakat ID'si, imza veya kısmi kart numarası içerebilir. Basit bir anahtar sunun: fişi katılımcılarla paylaş veya yalnızca rakamları paylaş. Bu, güveni korur ama grubu takibi engellemez.
İyi bir bölüm, insanlar birbirine nasıl geri ödeme yapacağını ve daha sonra bunu nasıl kanıtlayacağını bildiğinde tamamlanır. Bu özellik hesaplamaları kapanışa dönüştürür.
İki geçerli seçenek:
Link veriyorsanız, modüler ve bölgeye duyarlı yapın (mevcutluğu garanti etmeyin).
Kullanıcıların her kişi için birden fazla ödeme kaydetmesine izin verin. Örnek: “Sam Jordan'a 20$ nakit ödedi” ve “Sam 15$ banka transferi yaptı” gibi, bakiye sıfırlanana kadar. Her zaman gösterin:
Reimburse veya kayıt için sunun:
Para birimi, kullanılmış kur ve kim ödedi bilgisini dahil edin.
Kapatma şu şekilde olmalı:
Arşivlenen geziler aranabilir ve paylaşılabilir kalmalı; kazara düzenleme olmasın diye korunmalı.
Seyahat gider uygulamaları beklenenden daha hassas verilerle uğraşır: kim kiminle gezdiği, nereye gittikleri, ne kadar harcadıkları ve çoğu zaman fişlerdeki kişisel bilgiler. Erken güven inşa etmek, daha az churn ve destek talepleri demektir.
Veri hareket halindeyken ve depolandığında koruyun:
Fişler telefon numarası, sadakat ID veya kısmi kart numarası içerebilir. Hafif kontroller sunun:
Kullanıcılar bir gezi tamamlanınca silme bekleyebilir:
Ürün sağlığını izlerken gizliliğe saygılı olun. Odaklanın: özellik kullanımı (örn. “gider eklendi”, “gezi oluşturuldu”, “dışa aktarma yapıldı”)—fiş içerikleri veya hassas kişisel detaylar yerine. Hassas konum verisini yalnızca zorunluysa ve açık onay ile toplayın.
Davetler ve paylaşılan notlar suiistimal edilebilir. Davetler için hız sınırı, yeni hesaplar için doğrulama ve basit bir engelleme/şikâyet akışı ekleyin. Paylaşılan içerik için dosya tipleri, boyut limitleri ve tarama gibi temel moderasyon korumaları uygulayın.
Seyahat gider paylaşım uygulaması göndermek; gösterişli ekranlardan çok güvenle ilgilidir: matematik yanlışsa veya veriler kaybolursa kullanıcı geri dönmez. Test ve dağıtımı ürün özellikleri olarak ele alın.
Gider bölüşme algoritmanız etrafında birim testleri oluşturun:
Sıfır-tutar, iade, çoğaltılmış girişler ve yerleşim sonrası düzenlemeler gibi kötü durumları da kapsayın.
Çoğu hata günlük aksiyonlarda ortaya çıkar. Entegrasyon testleri ekleyin:
Küçük bir beta ile seyahat eden gruplarda doğrulayın:
App Store varlıklarını, onboarding ve hafif bir yardım merkezini hazırlayın (ör. /help sayfası). Destek e-postası ve uygulama içi “Geri bildirim gönder” kısayolu ekleyin.
Lansman sonrası, aktivasyonu (ilk gezi oluşturma), tutunmayı (geziyi yeniden açma) ve “yerleşim yapıldı” anını takip edin. Düşüşleri azaltan düzeltmeleri önceliklendirin: kafa karıştıran para birimi istemleri, yavaş gider ekleme akışı, davet hataları—ve ardından küçük, ölçülebilir sürümlerle yineleyin.
Hızlı inşa edip sık test ediyorsanız, güvenli yineleme sunan araçlar (anlık görüntüler ve geri alma gibi) hassas mantık—bakiye ve yerleşim hesapları gibi—üzerinde sık değişiklik yaparken özellikle faydalıdır.
Öncelikle bir ana grup seçin (arkadaşlar, çiftler, aileler veya ekipler) ve 5–10 kişiyi görüşün. Karışık para birimleri, hariç tutmalar, yarım ödenmiş faturalar, kaybolan fişler gibi en karmaşık gerçek senaryoları toplayın ve bunları UX ile hesaplamalar için test vakalarına dönüştürün.
Pratik bir MVP beş akışla başarılı olabilir:
Bu akışlar hızlı ve güvenilirse, kullanıcılar bir geziyi baştan sona tamamlayabilir.
Kullanıcıların harcamayı yakalayıp ‘kim ne kadar ödedi’ konusuna güvenmesini doğrudan iyileştirmeyen her şeyi erteleyin:
Hız ve doğruluk önce; otomasyon ancak çekirdek akış doğrulandıktan sonra gelsin.
Kullanıcıların gerçek gezilerde ihtiyaç duyduğu bölüşme yöntemlerini destekleyin:
Arayüzü basit tutun: akıllı varsayılanlar ve son kullanılan bölüşmeyi hatırlama işe yarar.
Hem saklayın:
Orijinal tutarı ve çevrilmiş değeri gösterin; kur ve zaman damgasını açıkça gösterin. Bir strateji seçin—kaydetme anındaki sabit kur (istikrarlı) veya günlük güncellemeler (dinamik)—ve bunu her gider için görünür yapın.
Bir yuvarlama politikası tanımlayın ve tutarlı uygulayın:
Tutarlılık, seçtiğiniz kuraldan daha önemlidir.
Tek elle, az dikkat gerektiren kayıt için tasarlayın:
Sık kullanılan giderlerin ~10–15 saniyede kaydedilebilmesi hedefleyin.
MVP için en düşük sürtünmeli ama güven veren giriş yöntemini seçin:
İzinler için öngörülebilir kurallar tutun:
Ayrıca, bir link yanlış grupta paylaşıldıysa iptal/yenileme imkanı verin.
Bir gezide hesaplayın:
Yerleşimler için, en az transferle herkesin kapatılmasını sağlayacak şekilde netleyin (borçluları alacaklılarla eşleştir) ve “A, B'ye $X ödedi” gibi kayıtlar tutun.
Bunu çekirdek özellik olarak ele alın, eklenti değil:
Bağlantı kesildiği için girişlerin kaybolmaması gerekir.
Birincil olarak hesaplama birimlerinizi otomatik testlerle kapsayın:
Ayrıca kötü durumlar: sıfır-tutar kalemler, iadeler/negatif giderler, çoğaltılmış girişler ve yerleşim sonrası düzenlemeler test edilmeli.