Emlak ilanlarını gezmek için bir mobil uygulamayı nasıl planlayacağınızı, tasarlayacağınızı ve oluşturacağınızı öğrenin—özellikler, veri kaynakları, teknoloji yığını, testler ve lansman ipuçları.
Kablolar veya MLS tartışmalarından önce, kimin için ve uygulamanın ne yapması gerektiği konusunda net olun. Emlak tarama genel görünse de, ana kullanıcıya göre ürün kararları dramatik şekilde değişir.
Optimize etmek için bir ana grup seçin:
Birden fazla kitleyi daha sonra destekleyebilirsiniz, ancak erken dönemde herkese yönelik bir yaklaşım genellikle kafa karıştırıcı gezinme ve şişirilmiş filtrelere yol açar.
İlk sürüm için tek bir çekirdek vaadi belirleyin. Yaygın seçenekler:
Bunlar netleştiğinde, ana işe hizmet etmeyen özelliklere “hayır” demek kolaylaşır.
Sadece indirme gibi gösteriş metriklerinden kaçının. Bunun yerine niyeti gösteren davranışlara bağlayın:
Vazgeçilemeyen kısıtları not edin:
Bu netlik, UX’den veri kaynaklarına ve teknoloji yığınına kadar her kararı yönlendirecektir.
Kod yazmadan önce, emlak uygulamanızın kullanıcıların halihazırda sahip olduklarından daha iyi çözdüğünü doğrulayın. Bu adım yanlış şeyi inşa etmenin aylarını kurtarır ve gerçekte gönderilebilecek bir MVP seçmenize yardımcı olur.
5–8 rakip uygulama seçin (ulusal portallar, yerel ajanslar ve bir “harita-öncelikli” ürün). Son yorumları okuyun ve bunları üç kategoriye ayırın: kullanıcıların sevdiği, nefret ettiği ve sürekli istedikleri.
Aşağıdaki desenleri arayın:
Gün birinci günde büyük ortaklıklar gerektirmeden ele alabileceğiniz boşlukları yazın.
Kullanıcı hikayelerini somut ve test edilebilir tutun. Örnekler:
Bir hikaye bir cümlede açıklanamıyorsa muhtemelen MVP için çok büyüktür.
MVP’niz iki şeyi kanıtlamalı: kullanıcılar ilgili ilanları hızlıca bulabiliyor ve geri gelmek istiyorlar. Pratik bir MVP genellikle arama + temel filtreler, harita gezinme, ilan detayları ve favoriler/kayıtlı aramalar içerir. Gerisini “iyi olur” olarak değerlendirin.
Tek şehirde başlasanız bile, birden çok şehir, diller, ek ilan kaynakları ve bölge başına farklı kurallar nasıl ekleyeceğinizi baştan belirleyin. Bu varsayımları belgeleyin ki veri modeliniz ve ekranlar büyümeyi engellemesin.
İlanlarınızın nereden geldiği her şeyi şekillendirir: kapsama, tazelik, özellik seti, yasal risk ve devam eden maliyetler. Bu kararı erken verin; çünkü kaynak değiştirmek genellikle veri modelinizi, aramayı ve hatta UX’i yeniden çalıştırmak demektir.
Genellikle dört yolunuz vardır:
Resmi entegrasyonları tercih edin:
Karar vermeden önce API kullanılabilirliği, kimlik doğrulama, kotalar, lisanslama, atıf gereksinimleri ve veriyi depolama, fotoğrafları gösterme veya bildirim gönderme konusundaki kısıtlamaları teyit edin.
Farklı kaynaklar aynı şeyi farklı tanımlar. Aşağı için bir normalizasyon katmanı planlayın:
Ayrıca gerçek dünya kalite sorunlarına hazırlıklı olun: çoğaltmalar, eski ilanlar, eksik fotoğraflar ve kaynaklar arasında çelişen bilgiler. Çoğaltmayı kaldırma, şüpheli kayıtları işaretleme ve alanlar eksik olduğunda kibarca geri dönüş kuralları oluşturun—kullanıcılar tutarsızlıkları hemen fark eder.
İyi bir emlak UX’i çoğunlukla hız, netlik ve güven üzerine kuruludur. Kullanıcılar çok sayıda seçeneği hızlıca taramak, ardından bir ilan “uygun” geldiğinde detaylarına inmek ister. Akışlar her adımda çabayı azaltmalı.
Çekirdekteki gezinme döngüsüyle başlayın ve uygulama boyunca tutarlı tutun:
Karşılaştırma için kartlar ve liste öğeleri tasarlayın: büyük fotoğraf, hiyerarşide güçlü bir fiyat ve 3–5 ana bilgi (yatak, banyo, metrekare, mahalle, “yeni”/“fiyat indirimi”) dokunmadan görülebilir olsun.
Detay sayfasında en önemli bilgileri üstte tutun; tam açıklama ve ek detaylar alt kısımda olsun.
Bir alt sekme çubuğu (bottom tab bar) genellikle bu ürün için en uygunudur: Home, Search, Map, Saved, Account. Herhangi bir listeden kullanıcı şu adımları izlemeli: detayları görüntüle → kaydet → iletişim/tur talep et → aynı kaydırma pozisyonuna geri dön.
Okunabilir yazı boyutları, güçlü kontrast ve büyük dokunma hedefleri (özellikle filtre chipleri, harita kontrolleri ve fotoğraf kaydırma) kullanın. Net fokus durumları ekleyin ve dinamik metin boyutu desteği sağlayın ki deneyim herkes için erişilebilir olsun.
Arama ve filtreler emlak uygulamalarının kazanıp kaybettiği yerdir. Kullanıcılar neden o ilanları gördüklerini hemen anlamalı ve durumu karışık hale getirmeden değiştirebilmeliler.
Zorunlu filtrelerle başlayın ve erişimi kolay yapın:
Daha sonra gerçek dünya kararlarını destekleyen ama ilk ekranda bunaltmayan filtreler ekleyin: metrekare, evcil hayvan izni, park yeri, aidat, okul bölgesi, yapım yılı, arsa büyüklüğü, açık ev ve “yeni listelenmiş.” Gelişmiş seçenekleri “Daha fazla filtre” panelinde tutun.
İki yaygın yaklaşım vardır:
Hangi yaklaşımı seçerseniz seçin, geri bildirim gösterin: yükleme durumları, güncellenen sonuç sayıları ve net boş durum mesajları (“Hiçbir ilan eşleşmiyor—maksimum fiyatı artırmayı veya aidatı kaldırmayı deneyin”).
Sonuçların üzerinde filtre chipleri kullanın (ör. “$400–600k”, “2+ yatak”, “Evcil hayvan kabul”). Hızlı geri dönüş için belirgin Temizle/Tümünü sıfırla ekleyin.
Varsayılan sıralama tahmin edilebilir olmalı (çoğunlukla “Yeni” veya “Önerilen” ve bir açıklamayla). Her zaman temel seçenekleri sunun: fiyat (artan/azalan), yenilik, mesafe (konum tabanlıysa) ve açık evler.
“Önerilen” kullanıyorsanız, kısa bir açıklama verin ve diğer sıralamalardan ilanları gizlemeyin.
Harita gezinme bir emlak uygulamasını “gerçek” hissettiren alandır. Kullanıcılar bir mahalleye kendilerini sabitleyebilir, yakındakileri görebilir ve yazmadan arama alanını hızlıca ayarlayabilir.
Platformlarınıza ve bütçenize uyan bir sağlayıcı seçin (Google Maps, Mapbox veya iOS için Apple MapKit). Temel pinlerin ötesinde planlayın:
Çoğu insan taramak için liste ve yönlenmek için harita arasında geçiş yapar. Bunları tek bir deneyim gibi hissettirin:
Harita UX’si yavaşlarsa hızla bozulur. Öncelik verin:
Konumu yalnızca işe yarıyorsa sorun (“Size yakın evleri bul”). Basit bir dille faydayı açıklayın ve alternatifler sunun:
İlan detay sayfası gezinmenin eyleme dönüştüğü yerdir. “Burada yaşayabilir miyim?” sorusunu hızlıca yanıtlamalı ve sonraki adımı netleştirmeli.
Güçlü bir fotoğraf, fiyat, adres/mahalle ve kullanıcıların taradığı 3–5 temel bilgiyi göstererek başlayın (yatak, banyo, büyüklük ve aylık maliyet detayları).
Hızlı yüklenen ve kaydırma, yakınlaştırma destekleyen bir fotoğraf galerisi ekleyin; net etiketleme yapın (ör. “Mutfak”, “Kat planı”, “Manzara”). Video veya 3D turlarınız varsa bunları birinci sınıf medya olarak gösterin, gizli linkler olarak bırakmayın.
Kompakt bir “Ana bilgiler” bloğu ve ayrı bir “Maliyetler” bloğu ekleyin ki kullanıcılar ücretleri kaçırmasın. Tipik öğeler:
İlan durumunu (Aktif / Beklemede / Kiralandı) net gösterin. “Son güncelleme” zaman damgası ve ilan kaynağını (MLS, broker feed, sahibi vb.) gösterin. Verinin gecikme ihtimali varsa bunu açıkça belirtin.
Birincil eylem olacak şekilde birkaç CTA sunun:
CTA’ları kaydırma sırasında sabit tutun ve mesajlarda bağlamı ön-doldurun (“12B ile ilgileniyorum, Mar 3’te müsait mi?”).
Aynı ilanı uygulamada açan temiz bir paylaşım bağlantısı destekleyin (gerekirse web sayfasına yedek). Derin linkler kullanın ki kullanıcılar SMS veya e-postadaki paylaşılan bağlantıya tıkladıklarında tam olarak bıraktıkları yerden devam edebilsin.
Hesaplar ve uyarılar bir gözatma uygulamasını alışkanlığa dönüştürür. Bu özellikleri “sadece bakmak” deneyimini engellemeden eklemek önemlidir.
Gezintiyi hesapsız tamamen kullanılabilir yapın: arama, harita, filtreler ve ilan sayfaları hemen çalışmalı. Hesap oluşturmayı yalnızca açık bir değer sağladığında sunun—favori kaydetme, cihazlar arası senkronizasyon veya uyarılar.
İyi bir varsayılan:
Bu üç özellik çoğu geri dönüş ziyaretini karşılar:
Küçük ama önemli bir detay: kaydettikten sonra ince bir onay gösterin ve bir kısayol sunun (“Favorileri Görüntüle”).
Uyarılar spesifik ve öngörülebilir olmalı:
Kaydedilmiş arama başına sıklık seçeneği verin (anında, günlük özet, haftalık) ve sessiz saatler ekleyin. Aşırı bildirim kullanıcıların uygulamayı kaldırmasına yol açar—bu yüzden bildirim paketleme ve “uyarıları duraklat” gibi kolay kontroller sağlayın.
Metin önemli: bildirimler “Ne değişti?” ve “Neden açmalıyım?” sorularını yanıtlamalı—abartı yapmadan. Örnek: “123 Oak St. ilanında 15k düşüş. Şimdi 585k.”
Kullanıcılar bir yeri beğendiklerinde sonraki adım sorusormak, tur istemek veya iletişim bilgilerini paylaşmak olmalı—uygulamadan çıkmadan. Bu, gezintinin gerçek leade dönüşme noktasıdır.
Bir kerede her seçeneği sunmak yerine birkaç net yol sunun:
CTA’ları uygulama boyunca tutarlı yapın: “Agent ile mesajlaş”, “Tur iste”, “Ara”.
Birden çok agent veya ekip destekliyorsanız, lead’ler ilan sahibi, bölge, dil veya müsaitlik gibi kurallara göre doğru kişiye gitmeli. İzleme ekleyin ki şu metrikleri ölçebilin:
Basit panolar bile lead’lerin kaçırılıp kaçırılmadığını görmenize yardımcı olur.
Sadece eylem için gereken bilgileri isteyerek sürtüşmeyi azaltın:
Giriş yapmış kullanıcılarda otomatik doldurma kullanın ve akıllı varsayılanlar (ör. “Bu hafta sonu”) sunun. Kullanıcı ürünü favorilediyse, mesaj bağlamını ön-doldurun.
Agentleri ve kullanıcıları korumak için oran limitleri, tekrarlayan gönderimlerde bot kontrolleri ve kötüye kullanımı bildirme yolları ekleyin. “Göndererek bu ilanla ilgili olarak iletişime geçilmesini kabul ediyorsunuz” gibi açık rıza metni gösterin ve takipler için ayarlardan kolayca çıkış imkanı sağlayın.
Teknoloji yığını MVP kapsamınıza, ekibinizin yetkinliklerine ve entegre edeceğiniz ilan kaynaklarına uymalı. Amaç hızlı ilerlemek ve mesajlaşma, kaydedilmiş aramalar veya zengin medya ekledikçe köşeye sıkışmamaktır.
En iyi kaydırma performansı, kamera özellikleri veya derin OS entegrasyonları gerekiyorsa, native (Swift/Kotlin) güçlü bir tercihtir.
Tek bir kod tabanı ve daha hızlı yineleme istiyorsanız, çapraz platform (React Native veya Flutter) genellikle emlak tarama uygulamaları için uygundur—çoğu ekran liste, harita ve detay sayfalarından oluştuğu için.
“Hibrit” webview’lar basit prototipler için işe yarayabilir, ancak genellikle harita akıcılığı ve karmaşık UI durumlarında zorluk çıkarır.
Sade bir MVP bile genellikle şunları gerektirir:
İlan alımını (MLS/IDX feedleri, ortaklar) ayrı bir modül olarak tutun ki bağımsızca evrilebilsin.
İlanlar ve kullanıcı verileri genellikle farklı depolarda olmalı: kullanıcı/hesap verileri için ilişkisel veritabanı, ilan keşfi için arama indeksi. Fotoğrafları/videoları nesne depolamada (S3-uygun) tutun ve hızlı yükleme için CDN kullanın.
Uygulamaya başlamadan önce API sözleşmelerini yazın (OpenAPI/Swagger yaygın). Arama, ilan detayları, favoriler ve izleme için uç noktaları tanımlayın. Bu, mobil ve backend ekiplerini hizalar, yeniden çalışmayı azaltır ve ileride web/admin araçları gibi istemcilerin eklenmesini kolaylaştırır. Daha fazla planlama bağlamı için bkz. /blog/app-architecture-basics.
Akışı (arama → harita → detay → kaydet → sorgu) hızlıca doğrulamak istiyorsanız, sohbet odaklı bir tanımla çalışan web uygulamaları üretebilen Koder.ai gibi bir platform, prototip oluşturmak için yardımcı olabilir. Özellikle bir admin paneli, lead panosu veya React ile MVP web deneyimi ve Go/PostgreSQL backend hızla kurup “planlama modunda” yineleme yapıp ürün yönü netleşince kaynak kodu dışa aktarmak için faydalıdır.
Bir emlak tarama uygulaması hassas sinyallerle (kullanıcının nerede olduğu, neleri kaydettiği, hangi evleri düşündüğü) uğraşır. Temelleri doğru yapmak kullanıcıları korur ve ileride destek yükünü azaltır.
Kanıtlanmış kimlik doğrulamaları kullanın (e-posta magic link, telefon OTP veya “Sign in with Apple/Google”) ve kendi özel çözümünüzü oluşturmaktan kaçının. Tokenları ve hassas değerleri platformun güvenli depolamasında saklayın (iOS Keychain, Android Keystore), düz tercihlerde değil.
Trafiği HTTPS/TLS ile şifreleyin ve backend’i gerçek kaynak kabul edin—app’den gelen değerlere güvenmeyin. Ödeme, kimlik doğrulama veya belge yüklemeleri varsa, bunlar için yerleşik sağlayıcıları kullanın.
İzinleri yalnızca gerektiğinde isteyin ve faydayı basitçe açıklayın. Konum “bana yakın” arama ve işe gidip gelme dostu filtreleri için faydalıdır, ama isteğe bağlı olmalıdır.
Rehber davetleri için kişiler kullanılıyorsa, bunun ayrı bir açık onay olmasını sağlayın. Bildirimler için kullanıcıya hangi türleri istediğini seçme imkanı verin: fiyat düşüşleri, kaydedilmiş alandaki yeni ilanlar veya durum değişiklikleri. Basit bir gizlilik sayfası gösterin (ör. /privacy) ve “Hesabı sil” yolu sağlayın.
Emlak uygulamaları görsel yoğun olur. Fotoğrafları sunucu tarafında sıkıştırın ve yeniden boyutlandırın, mümkünse modern formatlar kullanın ve görselleri kademeli yükleyin. Arama sonuçlarını ve ilan detaylarını önbelleğe alın, uzun listeler için sayfalama (veya sonsuz kaydırma) kullanın ve çevrimdışı temel (son görüntülenenler ve kaydedilenler) tutun.
Trafik patlamalarına hazırlıklı olun (yeni ilanlar, pazarlama kampanyaları). API oran limitleri ekleyin, fotoğraflar için CDN kullanın ve kritik sinyalleri izleyin: çökme oranı, yavaş ekranlar ve başarısız aramalar.
Kesintiler için uyarılar kurun ve veri feed sorunlarına karşı yedek yollar (yeniden dene, "tekrar deneyin" ve net hata mesajları) tasarlayın ki uygulama hizmet aksaklıklarında bile güvenilir kalsın.
Test ve lansman, bir emlak uygulamasının güven kazanma aşamasıdır. Kullanıcılar eksik bir özelliği affeder; yanlış sonuçları, bozuk iletişim akışlarını veya yavaş haritaları affetmez.
Üç katmanı kapsayın: çekirdek işlevsellik, cihaz kapsamı ve uç durumlar.
Mümkünse en yüksek riskli yollar için hafif otomasyon ekleyin (kurulum → arama → ilan aç → sorgu gönder). Harita etkileşimleri ve görsel sorunlar için manuel QA hâlâ önemlidir.
5–8 kişiye rehbersiz görevler verin: hedef bölgede bir ev bul, fiyat ve yatak sayısına göre daralt, iki ilan kaydet ve bir agent ile iletişime geç. Sürtüşmeleri izleyin:
Kararlara bağlı olayları izleyin: arama yapıldı, filtre uygulandı, ilan görüntülendi, kaydedildi, paylaşıldı, sorgu başlatıldı, sorgu gönderildi, tur istendi ve ayrılışlar. Tutarlı isimlendirme kullanın ve bağlam ekleyin (şehir, fiyat aralığı, kaynak, harita vs liste).
Mağaza varlıklarını hazırlayın (ekran görüntüleri, önizleme video, anahtar kelimeler), gizlilik detayları ve destek yollarını (ör. /privacy, /support) hazırlayın. Aşamalı yayımlama düşünün, çökme ve yorumları günlük izleyin ve ilk hafta yol haritasını gerçek kullanıma göre şekillendirin—varsayımlara göre değil.
Önce birincil hedef kitlenizi (alıcılar, kiracılar veya danışmanlar) ve v1 için tek bir “yapılacak iş” (gözatma, kısa listeleme veya iletişim/tur rezervasyonu) seçin. Ardından, niyeti gösteren başarı metriklerini tanımlayın (ör. aktif kullanıcı başına gelen sorgular, oturum başına kaydetmeler, 7 gün içinde tekrar oturumlar).
Pratik bir MVP genellikle şunları içerir:
Geri kalan her şey (gelişmiş mahalle verileri, karmaşık işbirliği araçları, zengin panolar) gerçek kullanım verilerini gördükten sonra eklenmelidir.
Hızlı rakip kontrolü yapın: 5–8 benzer uygulamayı inceleyin ve kullanıcıların neyi sevdiğini, neyi sevmediğini ve sıkça istedikleri özellikleri ayırın. Ardından test edebileceğiniz 3–5 somut kullanıcı hikayesi yazın (ör. “seyahat süresine göre filtrele”, “haritada sınır çiz”, “fiyat düşüşü bildirimi al”). Bir hikaye bir cümleye sığmıyorsa muhtemelen MVP için çok büyüktür.
Yaygın kaynaklar: dahili envanter, broker/danışman ortakları, toplayıcılar ve MLS.
Seçerken şunları önceden teyit edin:
Kaynakları sonradan değiştirmek genellikle veri modelinizin ve aramanızın yeniden tasarlanmasını gerektirir.
Gerçek zamanlı API daha taze durum/fiyat güncellemeleri sağlar ancak oran limitleri, kimlik doğrulama ve önbellekleme kurallarıyla gelir. Bir feed (saatlik/günlük) daha basit olabilir ama gecikmeli olabilir ve silinme işlemleri gerektirir. Birçok ekip maliyet ve tazelik dengesini sağlamak için hibrit bir yaklaşım (toplu feed + delta için API) kullanır.
Bir normalizasyon katmanı oluşturun ve kaynaklar arasındaki alanları standart hale getirin:
Ayrıca çoğaltma önleme kuralları, şüpheli kayıtları işaretleme ve veri eksik olduğunda kibarca geri dönüş yolları ekleyin—kullanıcılar çelişkili detayları hemen fark eder.
Alt çubuk (bottom tab) genellikle iyi çalışır: Home, Search, Map, Saved, Account. Sıkı bir gezinme döngüsü kurun: sonuç listesi ↔ harita ↔ ilan detayları. Liste kartlarını hızlı tarama için optimize edin: büyük fotoğraf, belirgin fiyat ve tıklamadan görülebilen 3–5 ana bilgi.
Öngörülebilir bir varsayılan sıralama kullanın (çoğu zaman Yeni Eklenen) ve aktif filtreleri çıkarılabilir chipler olarak gösterin. Filtrelerin anında uygulanıp uygulanmayacağına veya “Uygula” butonuna göre karar verin ve tutarlı kalın. Her zaman sunun:
Akıcı performans ve harita-list senkronuna öncelik verin:
Konum izni yalnızca gerekli olduğunda isteyin ve kullanıcı reddederse elle şehir/posta kodu girme seçeneği sunun.
Misafir modu ile gezinti yapmaya izin verin ve kaydetme/senkronizasyon/uyarı gibi değer sağladığında oturum açma isteyin. Bildirimler spesifik ve kontrol edilebilir olmalı:
Sıklık ayarları (anında/günlük/haftalık), sessiz saatler ve bildirimleri paketleme (throttling) özellikleri ekleyin.
