Hızlı gider notları için bir mobil uygulama nasıl oluşturulur: temel özellikler, UX akışları, çevrimdışı yakalama, fiş tarama, veri senkronizasyonu, güvenlik, test ve lansman hakkında bilgi edinin.

“Hareket halindeki gider notları” uygulaması, harcamayı gerçekleştiği anda yakalamak için tasarlanmış basit bir mobil araçtır—bir sokak köşesinde, takside, havaalanı sırasındayken. Öncelik hızdır: minimum yazma, birkaç dokunuş ve iş tamam. Uygulama uzun formlar veya kusursuz veri girişi gerektirirse, gerçek hayat yoğunlaştığında insanlar kullanmaz.
Bu tür bir uygulama, giderlerini takip eden serbest çalışanlar, hafif geri ödeme kayıtlarına ihtiyaç duyan küçük ekipler ve birden fazla para birimi ve fiş ile uğraşan gezginler için özellikle yararlıdır. Ayrıca haftanın sonunda o “18,40 ₺” harcamasının ne olduğunu sıkça unutan herkes için faydalıdır.
Makale sonunda şu amaçlarla bir MVP gider notları uygulaması için net bir planınız olacak:
Ayrıca birkaç pratik karar vereceksiniz—kullanıcılarınız için “hızlı yakalama”nın ne anlama geldiği, bütçenize uyan tarama yaklaşımı ve gizliliği sürtüşme yaratmadan nasıl ele alacağınız gibi.
Amaç tam bir muhasebe sistemi oluşturmak değil. Günlük olarak düşünmeden kullanılabilecek bir sürümle başlayın. Gerçek kullanım desenlerini gördükçe daha akıllı öneriler, daha iyi raporlar ve derin entegrasyonlar ekleyebilirsiniz.
Bu rehber odaklı kalır: amaç gereksiz karmaşıklığa kaymadan gönderilebilir ilk sürümü oluşturmak.
Uygulamanız hareket halindeki gider notları içinse temel ihtiyaç basittir: gider gerçekleştiği anda yakalanmalı, detaylar dağınık olsa bile. İnsanlar kasada “muhasebe yapmak” istemezler—ileride güvenebilecekleri hızlı bir kayıt isterler.
Çoğu kullanıcı üç işi takip eder:
Hız sorunları genellikle gider takip alışkanlıklarını bozar:
Uygulamanızın diğerlerinden daha iyi yapacağı bir “varsayılan an” seçin: kahve/taksi/ hareket halindeyken yemek—bir el telefonda, kötü ışık, sınırlı zaman, kesik sinyal. Bu senaryo MVP kararlarınızı yönlendirmeli (büyük düğmeler, minimum yazma, zarif çevrimdışı davranış).
Erken ölçülebilir sonuçları tanımlayın:
Bir gider notları uygulaması, temel bilgileri saniyeler içinde yakalayıp sonra geri çekildiğinde başarılı olur. MVP için güvenilir bir “Gider Ekle” akışına odaklanın: kaydı güvenilir şekilde kaydetsin ve sonra kolayca bulunabilsin.
Bunları vazgeçilmez olarak başlatın:
Sadece hızlı girilebilen ve açıkça değerli olanları ekleyin:
Otomatik doldurma sürtüşmeyi azaltır ve doğruluğu artırır:
Erken karar verin: “not” serbest metin mi yoksa birkaç şablon (ör. “Havaalanına taksi”, “Müşteri öğünü”) mu sunacaksınız? MVP için serbest metin yeterlidir. Daha sonra hız için birkaç hızlı seçenek ekleyebilirsiniz.
MVP kapsamı: gider oluşturma, düzenleme, listeleme/arama, temel kategoriler, fotoğraf ekleme, basit toplamlar.
Sonra: OCR tarama, akıllı kategori önerileri, dışa aktarmalar, çoklu para birimi dönüşümleri, ekip paylaşımı.
İyi bir gider notları uygulaması, bir hesabı öderken, bir toplantıya yürürken veya çantalarla uğraşırken yakalanmak üzere tasarlanmıştır. UX hedefi basit—kullanıcı düşünmeden saniyeler içinde kullanılabilir bir kayıt oluşturmalı.
Kullanıcıların uygulamayı aramasını istemeyin. En az bir hızlı başlatma seçeneği sunun:
Uygulama açıldığında doğrudan yakalama ekranında olmalı—bir gösterge panosunda değil.
İki model iyi çalışır:
Adım adım seçerseniz, adım sayısını küçük tutun ve opsiyonel alanların atlanmasına izin verin.
“Doğru” girdiyi kolaylaştırın:
Tutar için büyük bir sayısal giriş kullanın ve metin alanlarını opsiyonel tutun.
Gerçek hayat dağınıktır. Kullanıcının bir tutarı (veya sadece bir fiş fotoğrafını) aldıktan sonra Savea dokunup hemen devam etmesine izin verin, sonra düzeltme yapabilsin.
Pratik akış:
Hızlı yakalama, dokunması veya okunması zor olursa başarısız olur. Büyük dokunma hedefleri, açık etiketler (sadece ikon olmasın), güçlü kontrast ve güvenilir karanlık mod desteği kullanın. Birincil eylem (Save) tek elle ulaşılabilir olmalı.
Fiş yakalama bir gider notları uygulamasını ya zahmetsiz hissettirir—ya da can sıkıcı yapar. Hedefiniz basit: kuyrukta beklerken veya taksiye yürürken bile minimum sürtüşme ile okunabilir bir fiş fotoğrafı almak.
Kamera akışını “sadece çalışır” şekilde tasarlayın:
Tarama opsiyonel olmalı. Kullanıcı fotoğrafı anında kaydedip devam edebilmeli, sonra çıkarım arka planda gerçekleşsin.
Cihazda OCR gizlilik, çevrimdışı kullanım ve hız (yükleme yok) için iyidir. Eski cihazlarda, alışılmadık fiş formatlarında veya düşük kaliteli fotoğraflarda zorlanabilir.
Sunucu tabanlı OCR cihazlar arasında daha tutarlı olabilir ve merkezi olarak geliştirmesi daha kolaydır, fakat yükleme süresi ekler, ağ erişimi gerektirir ve gizlilik/uyumluluk soruları doğurur. Bu yolu seçerseniz, neyin yüklendiği ve ne kadar süre saklandığı konusunda açık olun.
Pratik bir yaklaşım hibrittir: önce cihazda deneyin, sonra kullanıcı çevrimiçi ve onaylıysa sunucu OCR sunun.
Raporlama işlevselliğini güçlendiren yüksek güvenilirlikli alanlarla başlayın:
Satır kalemleri bekleyebilir; karmaşıklık ekler ve genelde basit gider raporları için gerekli değildir.
Her zaman temiz bir manuel giriş ekranı sağlayın: dokunarak düzeltilebilen tutar/tarih, satıcı önerileri ve “Okunamadı olarak işaretle” seçeneği.
Hafifçe eşleşenler için uyarılar koyun: yeni bir fiş, toplam + zaman aralığı + satıcı benzerliği ile mevcut bir fişle yakından eşleşiyorsa kullanıcıya onaylatın; engelleme yapmayın.
Bir gider notları uygulaması, bir metroda, müşterinin bodrumunda veya bir otoparkta çalışıyorsa “hareket halinde” gibi hissettirir. Çevrimdışını varsayılan sayın: kullanıcı bir gider ekleyebilmeli, fiş fotoğrafı iliştirebilmeli ve devam edebilmeli—sinyal olsun olmasın.
Kullanıcı Savee dokunduğunda gideri cihazda hemen saklayın. Ağ çağrısına bağlı kılmayın. Bu tek karar çoğu hayal kırıklığını ortadan kaldırır ve kaybolan kayıtları önler.
Yerel depolama için, telefonda küçük şifreli bir veritabanı (ör. şifreli SQLite tabanlı bir mağaza) düşünün. İçermeli:
Senkronizasyon uygulamaları garipleşebilir. Bir kural seçin ve bunu iletişimde açık yapın.
Ayrıca bir öğe bir cihazda silindiğinde diğerinde düzenlendiğinde ne olacağını kararlaştırın. Yaygın yol “soft delete” (silindi olarak işaretleme, senkronize etme, sonra temizleme).
Fiş resimleri büyük dosyalardır ve genellikle ilk başarısız olan şeydir. Görselleri yerelde kaydedin, sonra çevrimiçi olduğunda arka planda yükleyin (tercihen Wi‑Fi’de olacak şekilde, kullanıcı onaylarsa hücresel de olabilir). Yüklemeler yeniden başlatılabilir olmalı ki kopuk bağlantı her şeyi sıfırlamasın.
Kullanıcılara görünür, sakin durumlar gösterin:
Bu, senkronizasyonu bir gizem olmaktan çıkarıp deneyimin öngörülebilir bir parçası yapar.
Harika bir gider notları uygulamasını birçok farklı araçla inşa edebilirsiniz. Amaç “en iyi” yığını seçmek değil—ekibinizin gönderebileceği ve sürdürebileceği birini seçmektir.
Ekip zaten Swift/SwiftUI veya Kotlin/Jetpack Compose biliyorsa, yerel uygulamalar genelde cilalı, güvenilir bir yakalama deneyimi için en hızlı yoldur (kamera, çevrimdışı depolama, paylaşım menüsü).
Her iki platforma da küçük bir ekiple ihtiyacınız varsa, bir çapraz platform seçeneğine karar verin:
Pratik MVP kuralı: bir mobil mühendisiniz varsa çapraz-platform; ayrı iOS + Android yeteneğiniz varsa yerel seçin.
“Edit expense”, “attach receipt” ve “sync status” gibi özellikler spaghetti olmasın diye basit, tutarlı bir desen kullanın:
Aşırı mühendislik yapmayın: UI, durum ve veri katmanı arasında temiz bir ayrım genelde yeterlidir.
Çoğu MVP için dört şey gerekir:
Managed bir backend (Firebase, Supabase) kurulum süresini kısaltır. Özel bir backend (Node/Django/Rails) karmaşık raporlama veya sıkı uyumluluk bekliyorsanız daha fazla kontrol sağlar.
Hızlı ilerlemek ve tüm boru hattınızı yeniden kurmamak isterseniz, Koder.ai gibi bir platform da MVP aşamasında faydalı olabilir: temel akışları sohbet tabanlı bir iş akışıyla prototipleyebilir, sonra kaynak kodu dışa aktarabilirsiniz. React web panel + Go + PostgreSQL gibi yaygın MVP seçimleriyle uyumludur ve planlama modu, anlık görüntüler ve geri alma gibi özellikler sunar.
Uç noktaları temel nesneler etrafında tasarlayın:
POST /expenses, PATCH /expenses/{id}POST /receipts (yükleme), bir giderle ilişkilendirmeGET /expenses?from=&to=&category=POST /exports (indirilebilir bir dosya döner)Çapraz-platform geliştirilmeyi hızlandırır ama kamera/OCR kenar durumları için ekstra çaba gerektirebilir. Managed backend'ler erken dönemde maliyeti düşürür; ölçeklenme ve net bir yol haritası varsa özel backend uzun vadede daha ucuz olabilir. Emin değilseniz managed ile başlayın ve ileride taşınma yolu bırakın (bkz. /blog/offline-sync-basics).
Bir gider notları uygulaması hızla kişisel ve iş hassasiyeti taşıyan verilerin saklandığı bir konteyner haline gelir. Güvenlik ve gizliliği “sonradan iyi olur” işi değil, temel ürün gereksinimi olarak ele alın.
Banka bilgisi saklamıyor olsanız bile, harcama alışkanlıklarını veya iş faaliyetlerini ortaya çıkarabilecek bilgilerle uğraşırsınız:
Basit, savunulabilir bir temel ile başlayın:
Üçüncü taraf OCR kullanıyorsanız, neyin yüklendiği, ne kadar saklandığı ve tedarikçilerin bunu model eğitimi için kullanıp kullanamayacağı konusunda açık olun.
İzinler bir güven anıdır. Noktada kullanımda isteyin, sade bir dille açıklayın:
Konumu varsayılan istemeyin; çoğu kullanıcı gider notları için bunu beklemez.
Çoğu MVP için e-posta + magic link/OTP yeterlidir. Hedef kullanıcı kurumsa SSO sonradan eklenebilir.
Ayrıca uygulamayı açma veya fişleri görüntüleme için cihaz kilidi (Face ID/Touch ID/PIN) seçeneği düşünün—özellikle paylaşılan cihazlarda.
Gizlilik kontrollerini görünür yapın:
Açık ayarlar destek taleplerini azaltır ve kullanıcıların gerçek fişleri uygulamada saklamaya güvenmesini sağlar.
İyi bir organizasyon, hızlı not yığınını gerçekten raporlanabilir bir şeye dönüştürür. Genelde üç şeye dayanır: kullanımı zorlaştırmayan bir kategori modeli, seyahat için “yeterince iyi” para birimi yönetimi ve tekrarlı yazmayı ortadan kaldıran hafif öneriler.
Çoğu kişi için tanıdık, kısa bir liste ile başlayın (ör. Meals, Transport, Lodging, Office, Entertainment, Fees). Tercih edilmez seçim yükünü azaltmak için ~10–12 altında tutun.
Sonra özel kategoriler bir kaçış yolu olarak ekleyin. İki pratik kural:
Akıllı hissettirmek için “AI” gerekmez. Küçük bir kural katmanı oluşturun:
Bu, yakalamayı hızlandırır ama otomasyonu zorunlu kılmaz.
Hem şunu saklayın:
Dönüştürme için günlük kur kullanmak (MVP için yeterli). Kullanılan kuru ve tarihi gösterin ki toplamlar gizemli olmasın.
İş geri ödemelerine odaklanmıyorsanız KDV’yi opsiyonel tutun: “Vergi dahil mi?” gibi bir açma/kapama veya “Detay ekle” altında gizli bir “Vergi” alanı.
“Geçen ay X için ne harcadım?” sorusuna cevap verebilmeli. Tarih aralığı, kategori, tutar ve satıcı filtreleri ile notlar ve satıcı isimleri üzerinde basit anahtar kelime araması destekleyin.
Giderleri yakalamak işin yarısıdır—nihayetinde muhasebeye teslim edilebilecek, geri ödeme portalına yüklenebilecek veya saklanabilecek bir şey üretmeniz gerekir. Dışa aktarmalar uygulamayı pratik bir araca dönüştürür.
Oluşturması kolay ve yaygın kabul gören formatlarla başlayın:
Daha sonra araç entegrasyonları eklemeyi planlıyorsanız (ör. muhasebe platformları), dışa aktarma veri modelinizi girişlerin nasıl saklandığını değiştirmeden entegrasyon ekleyebilecek şekilde tasarlayın.
Rapor deneyimini öngörülebilir tutun:
Bir uygulama proje/müşteri destekliyorsa isteğe bağlı filtre ekleyin ama zorunlu yapmayın.
Raporla birlikte fişlerin nasıl iletileceğine karar verin:
Hangi yolu seçerseniz seçin, bir fişin eksik olduğunu açıkça gösterin.
Tutarlı adlar kullanın:
expenses_2025-01-01_to_2025-01-31_jordan.pdfexpenses_2025-01_project-acme.csvHafif bir uygulama bile dışa aktarırken şu alanları içermeli:
Bu detaylar, “Bu ne zaman girildi ve kaynağı ne?” sorularını azaltır.
Bir gider notları uygulaması dağınık anlarda başarısız olur: kötü aydınlatma, sinyal yok ve yürürken tek elle kullanım. Testler sadece “mutlu yol” gösterilerine değil bu gerçek durumlardaki davranışa odaklanmalı.
Çekirdek akışı (yakala → kaydet → senkronize et → dışa aktar) koruyan birkaç testle başlayın:
Birkaç gerçek cihazda manuel test yapın (sadece bir amiral gemisi değil):
Birkaç “hissedilen” zamanlamayı ölçün ve buildler arasında tutarlı tutun:
Cihaz-spesifik sorunları yakalamak için çökme raporlamasını erken kurun. Ana adımlar için hafif olay takibi ekleyin (aç capture, fiş çekildi, OCR başarılı/başarısız, sync başarılı/başarısız) ve hassas metin veya tam fiş resimlerini kaydetmeyin.
Gerçekten seyahat eden veya gider gönderen 10–30 kişiyi davet edin. Geri bildirimi yapılandırılmış tutun:
Sorunsuz bir lansman her şeyin olması değil—ilk kullanım deneyiminin bir dakikadan kısa sürede uygulamanın değerini göstermesidir: bir gider kaydet, fiş ekle ve sonra bul.
Mağaza varlığı ve uyumluluk detaylarını erken hazırlayın ki çıkış haftasında acele etmeyin:
Açılışı kısa ve eylem odaklı tutun:
Bir modeli seçin ve anlaşılır tutun:
(Koder.ai ile inşa ediyorsanız, bu katmanlar aşamalı yeteneklere kolayca uyar: MVP ile ücretsiz başlayın, gelişmiş özellikleri Pro/Business altında sınırlandırın, Enterprise seçeneklerini uyumluluk/özelleştirme için saklayın.)
Kullanıcı değerine bağlı davranışı izleyin:
Gerçek kullanım verisini önceliklendirerek ilerleyin:
Hız ve güvene odaklanın: kullanıcılar dağınık bilgiler olsa bile bir gideri saniyeler içinde kaydedebilmeliler.
İyi bir MVP genellikle şunları destekler:
“Tek elle, zaman yok, kötü ışık, sinyal zayıf” anı için tasarlayın.
Pratik MVP tercihleri:
İyi bir asgari set şunlardır:
Kullanıcıları yavaşlatmadan kategorileri yönetmenin yolu basit bir başlangıç listesi kullanmaktır (yaklaşık 10–12 kategori).
Ardından özel kategoriler ekleyin:
Fişleri opsiyonel ve sürtüşmesiz yapın:
OCR'ı engel değil, arka planda çalışan bir adım olarak düşünün.
Cihaz üzeri OCR:
Sunucu tabanlı OCR:
Pratik bir uzlaşma : önce cihazda dene, çevrimiçi ve onaylıysa sunucu OCR sun.
Çevrimdışını varsayılan sayın: önce yerel kaydet, sonra senkronize et.
Ana uygulamalar:
Tahmin edilebilir ve düşük sürtüşme sağlayın:
İzinleri kullanım anında isteyin ve nedenini sadece açıklayın:
Ayrıca, fişler hassas olabilir; gerekirse uygulama düzeyinde kilit (Face ID/Touch ID/PIN) sunun.
MVP için insanların gerçekten kullanacağı formatlara öncelik verin:
Denetim için gerekli alanları ekleyin:
Essentials dışında her şeyi opsiyonel tutun ki kullanıcılar yine de hızlıca kaydedebilsin.
Fişlerin raporla birlikte taşınması konusunda hafif bir tercih yapın: linkler (hafif) veya ekli küçük resimler (denetçiler için daha iyi).