niranar.com'dan Öğrendiklerimiz: Platform Kurmanın Gerçek Bedeli

Bu serinin ilk yazısı niranar.com'un ne inşa ettiğini anlatıyordu. Ara yazılar mimariyi, teknolojiyi, aramayı, veriyi, UX kararlarını ve beta stratejisini derinlemesine ele aldı. Bu son yazı farklı bir konuşma başlatıyor: Bu yolculuk boyunca gerçekte ne öğrenildi?

"Öğrenme" kelimesi genellikle zararsız bir sözcük gibi görünür. Ama gerçek öğrenmeler zararsız değildir — onlar bilinçli tercihlerdir ve her tercihin bir bedeli vardır. Bu yazı niranar.com'un hangi bedelleri ödediğini, neden ödediğini ve bir sonraki ekibin bu bedeller hakkında ne bilmesi gerektiğini ele alıyor. Hata kabulleri değil, ödünleşim belgeleri. Seri boyunca anlatılan her kararın güvenilirliği, bu belgelerin dürüstlüğüne bağlı.

Beş karar öne çıkıyor: Supabase'in tek BaaS olarak seçilmesi, Leaflet'in harita çözümü olarak tercih edilmesi, beta aşamasında auth ve ödemenin kapsam dışı bırakılması, EUR fiyatlandırma ile Türkçe arayüzün birlikte kullanılması ve Claude Code ile geliştirmenin neyi değiştirip neyi değiştirmediği. Her biri ayrı bir kararı temsil ediyor; hepsi birlikte tek bir tablo oluşturuyor: bu ürünü bu bağlamda inşa etmenin gerçek maliyeti.

Ders 1: Supabase Tek BaaS Olarak — Hız ile Ölçek Tavanı Arasındaki Mesafe

niranar.com'un backend kararlarının merkezinde Supabase var. Tek bir geliştirici için bu tercih son derece mantıklıydı: veritabanı, API katmanı ve henüz devreye alınmamış kimlik doğrulama altyapısı tek bir hizmette birleşiyor. Entegrasyon maliyeti minimum, öğrenme eğrisi kısa, operasyonel yük düşük. Servis bağımlılıkları minimumda tutulduğunda hem geliştirme hızı artar hem de sorun ayıklaması kolaylaşır — tek bir geliştirici için bu denklemin değeri ölçülemez.

Bu tercihin bedeli ise ölçek tavanda görünür hale geldi.

300.000'i aşkın ilan üzerinde konum, tarih, misafir sayısı, mülk türü ve özellik kombinasyonu içeren çok parametreli aramalar PostgreSQL sorguları üzerinden yürüyor. PostgreSQL'in tam metin araması bu iş için işe yarıyor — ama Elasticsearch veya benzeri ayrılmış bir arama motoru, bu görev için tasarlanmış araçlar sağlıyor. Alakasallık sıralaması, faceted search, fuzzy matching, yazım hataları toleransı, eş anlamlı yönetimi — bunların tümü PostgreSQL'de uygulanabilir ama her biri önemli ek mühendislik çabası gerektiriyor. Bir arama motorunda bu özellikler birinci sınıf vatandaştır; PostgreSQL'de ise üstüne inşa edilmesi gereken katmanlar.

Beta aşaması için bu ödünleşim bilinçli ve savunulabilir bir karardı: ek servis yok, ek maliyet yok, ek mimari karmaşıklık yok. Arama kalitesi, rekabetçi farklılaşma açısından henüz kritik eşikte değil. Kullanıcı "Bodrum'da villa" arıyor ve sonuçlar geliyor; bu kullanıcı için PostgreSQL yeterli. Ama bir sonraki ekip bu tavanı görmelidir: kullanım büyüdüğünde, kullanıcı beklentileri olgunlaştığında ve arama kalitesi bir farklılaşma faktörü haline geldiğinde, Supabase PostgreSQL'in üstüne arama servisi eklemek ya da ayrı bir motor entegre etmek gerekecektir. Bu karar ertelenmiş, iptal edilmemiş. Ertelenmiş kararların görünür olması, gizlenmesinden çok daha değerlidir.

Teknik ayrıntılar için bkz. niranar.com'da Arama Mimarisi ve Teknoloji Yığını.

Ders 2: Leaflet'i Google Maps Yerine Seçmek — Ücretsiz Bir Maliyet

Harita kararı net görünüyordu: Google Maps API, kullanım bazlı faturalandırma yapıyor. Bir pre-revenue beta için sorgular arttıkça büyüyen bir maliyet kalemi hem finansal hem operasyonel bir risk oluşturur. Tahmin edilemeyen faturalar, gelir olmadan ölçeklenen bir ürün için önemli bir belirsizlik kaynağıdır. Leaflet açık kaynak, API anahtarı yok, istek başına ücret yok — bu çerçevede karar açıktır.

Ama "ücretsiz" gerçekten bedelsiz değil — sadece farklı bir para birimiyle ödeniyor: geliştirme zamanı.

Google Maps, coğrafi kodlama, ters coğrafi kodlama, places autocomplete, tile yönetimi, cluster görselleştirme ve mobil dokunma etkileşimlerini iyi tanımlanmış SDK'larla hazır sunuyor. Bu özellikler, bir tatil kiralama platformunun harita deneyimi için kritik: kullanıcı bir şehir adı yazıyor, platform coğrafi sınırları anlıyor, haritada ilgili mülkler kümeleniyor, dokunma ile büyütme pürüzsüz çalışıyor. Google Maps bu akışın büyük çoğunluğunu otomatik olarak yönetiyor.

Leaflet'te bunların her birinin ayrıca ele alınması gerekiyor. Tile provider'ın seçimi ve yönetimi bağımsız bir karar. Geocoding servisi bağımsız olarak entegre edilmek zorunda — Nominatim, Mapbox, ya da başka bir kaynak. Mobil UX için dokunma ve jest işlemleri özel geliştirme gerektiriyor. Cluster mantığı ek kütüphane veya özel kod istiyor.

niranar.com bu bedeli ödedi. Harita çalışıyor, Leaflet entegrasyonu tamamlandı, kullanıcı mülkleri haritada görüntüleyebiliyor. Ama bu sonuca ulaşmak, Google Maps'in hazır sağladığı şeylerin önemli bir kısmının manuel olarak inşa edilmesini gerektirdi. Seçim yanlış değildi — pre-revenue beta için tahmin edilemeyen API faturaları gerçek bir risk vektörüdür ve bu riski kontrol altına almak, mühendislik zamanı harcamayı meşrulaştırıyor. Ama bir sonraki ekip bu ödünleşimi görmeli: Leaflet "ücretsiz harita" değil "zaman yatırımı gerektiren harita"dır. Ölçek büyüdüğünde ve harita UX'i bir farklılaşma noktası haline geldiğinde, bu denklemi yeniden değerlendirmek gerekebilir.

Ayrıntılar için bkz. API Entegrasyonları ve Harita Mimarisi.

Ders 3: Auth Yok, Ödeme Yok — Beta'nın İçeriden Hissi

niranar.com Beta Stratejisi yazısı bu kararın stratejik mantığını açıkladı: keşif önce gelir, işlemler sonra. Bir tatil kiralama platformunda temel değer başlangıçta keşif değeridir; ödeme altyapısını doğrulamadan önce kullanıcıların gerçekten arama yapıp yapmadığını anlamak gerekiyor. Katalog ve arama deneyimi doğrulandıktan sonra kimlik doğrulama ve ödeme aktive edilecek.

Bu mantık nesnel olarak doğru. Ama bu öğrenme o yazının yazmadığı bir boyutu kapsıyor: Bu stratejiyi içeriden yaşamanın nasıl bir his olduğu.

İşlevsel bir arama deneyimi sunduğunuzda, gerçek sonuçlar döndürdüğünüzde, bir kullanıcının Fethiye'de havuzlu bir villa bulmasını sağladığınızda — ve ardından durmak zorunda kaldığınızda — güven gerekiyor. Kullanıcı hayal kırıklığı yaşıyor, "neden rezervasyon yapamıyorum?" diye soruyor. Siz ise onun adına bir önceki adımı, yani keşfi, doğrulamaya çalıştığınızı anlıyorsunuz. Ama bu öncelik sırası kullanıcıya görünür değil — kullanıcı eksik bir ürün gördüğünü düşünüyor, siz stratejik bir kapsam kararı uyguladığınızı biliyorsunuz.

Dönüşümsüz bir platform işletmenin psikolojik maliyeti var. Kullanıcı sinyalleri var ama satış yok. Arama etkileşimi var ama taahhüt yok. Katalog büyüyor ama henüz işlem gerçekleşmiyor. Bu belirsizlik içinde çalışmak, stratejik netliği korumayı gerektiriyor: şu anda ölçtüğün şey ilgi mi, arama mı, hangi filtreler kullanılıyor — ve bu veriler ödeme altyapısından önce gelmesi gereken sinyaller.

Bu durumun "rahat" olduğunu söylemek yanlış olur. Discovery-first stratejisi teoride zarif görünür: keşfi önce doğrula, işlemleri sonra ekle. Ama teori pratiğe dönüştüğünde, öncelik sırasının doğru olduğunu gerçek veriyle kanıtlamadan önce belirsizlik içinde çalışmak gerekiyor. Bir sonraki ekip şunu bilmeli: bu sabır sadece kullanıcıların beklentilerini yönetmekle değil, aynı zamanda kendi belirsizliğinizi yönetmekle ilgili.

Ders 4: EUR Fiyatlandırma, Türkçe Arayüz — İki Kitleye Tek Arayüzle Hizmet Vermek

niranar.com'un en ilginç gerilimi tek bir sayfada görünür: tüm içerik Türkçe, tüm fiyatlar EUR.

Bu bir hata değil, bilinçli bir tasarım kararı. EUR fiyatlandırma uluslararası turistleri hedefliyor — Akdeniz Türkiye'sine gelen Avrupalı ve uluslararası ziyaretçiler için beklenen para birimi EUR'dur; TRY döviz kuru belirsizliği, yabancı misafire ek bir karmaşıklık katmanı oluşturur. Türkçe UI ise yerel arz tarafını hedefliyor — mülklerini listelemek isteyen Türk ev sahipleri için tanıdık, güven verici bir deneyim. Mantık her iki yönde de tutarlı.

Ama bu ikili hedefleme kaçınılmaz bir UX gerilimi yaratıyor ve bu gerilim pratikte somutlaşıyor.

Uluslararası bir turist platforma geldiğinde Türkçe bir arayüzle karşılaşıyor. Navigasyonu anlayamayabilir, kategorileri okuyamayabilir, "Destek" sayfasını bulamayabilir. Alanya'daki bir mülkü seçip detay sayfasına gittiğinde, daha fazla bilmek istediğinde iletişim kuramıyor olabilir. Bu kullanıcı için deneyim gerçek anlamda kısmi kalıyor — rezervasyon olmasa da, keşif bile tamamlanamayabilir.

Öte yandan Türk bir ev sahibi EUR fiyatlarıyla karşılaşıyor. Yerel pazar referansları TRY üzerinden düşünülürken mülk fiyatını EUR olarak ifade etmek zihinsel bir dönüşüm gerektiriyor. Döviz kuru dalgalanmaları bu hesabı sürekli güncelleme ihtiyacı doğuruyor.

Her iki kitleye de tek bir arayüzle ulaşmak mümkün — ama her iki kitle için de tam anlamıyla optimize edilmiş bir deneyim sunmak güç. Bu ödünleşim, pazar yeri tasarımının klasik sorusunu somutlaştırıyor: "tek arayüz mi, çoklu deneyim mi?" Nisan 2026 lansmanında dil seçeneği veya lokalizasyon katmanı eklenirse bu gerilim çözülebilir. Ama çözümün maliyetini — çoklu dil yönetimi, içerik çevirisi, UX paralelliği — baştan görmek, bu kararı daha iyi hazırlıklı bir şekilde almayı sağlar.

UX kararlarının kapsamlı analizi için bkz. UX Kararları ve Tasarım Felsefesi.

Ders 5: Solo Geliştirici + Claude Code — AI Neyi Değiştirir, Neyi Değiştirmez

niranar.com tek bir geliştirici tarafından Claude Code kullanılarak inşa edildi. 300.000'i aşkın ilanı kapsayan katalog, çok parametreli arama deneyimi, Leaflet harita entegrasyonu, özel takvim uygulaması, iki taraflı navigasyon yapısı, mobil uyumlu tasarım — tüm bunlar tek kişilik bir ekipten çıktı.

Bu gerçek, AI destekli geliştirmenin olanaklarını somut biçimde gösteriyor. Geçmişte bu kapsamda bir ürünü tek başına tamamlamak aylar sürerdi, belki yıllar. Claude Code bu denklemi temelden değiştirdi. Ama bu yazı o hikâyenin tamamı değil — diğer yarısı, Claude Code'un neyi değiştirmediği hakkında.

AI'ın değiştirdiği şeyler somut: Tekrarlayan kod örüntülerinin yazım hızı belirgin biçimde arttı. Entegrasyon boilerplate'leri hızlandı. Belirli özelliklerin uygulanması sırasında referans ve örnek bulma süreci kısaldı. Hata ayıklama döngülerinde çözüm önerileri hızlı geldi. Bunların bileşimi, tek bir geliştiricinin tarihsel olarak bir ekibin tamamlaması gereken kapsamda çalışmasına olanak tanıdı. Bu etki gerçek ve ölçülebilir.

Ama mimari kararlar hâlâ insana ait. Supabase mi, yoksa ayrı bir arama motoru mu? Leaflet mi, Google Maps mi? Auth'u beta dışında bırakmak mı? EUR fiyatlandırma mı, TRY mi? Bu soruların hiçbirini AI çözmedi — çünkü bu sorular teknik değil stratejik. Doğru cevap, mevcut kısıtlara, risk toleransına, bütçeye ve ürünün hedeflediği kitleye bağlı. Bu değerlendirme, bağlamı anlayan ve ödünleşim maliyetlerini taşıyacak olan kişiye ait. AI bu bağlamı taklit edebilir ama içinde yaşamıyor.

Kapsam yönetimi için de aynı durum geçerli. AI yazmayı kolaylaştırır; neyin yazılıp neyin yazılmayacağını karar vermeyi kolaylaştırmaz. Beta'da auth ve ödeme olmaması kararı, teknik bir kısıtın değil stratejik bir öncelik sıralamasının sonucuydu. Bu sıralamayı belirlemek insan yargısı gerektirdi — ve o yargı doğruydu.

Bir sonraki ekip şunu anlamalı: Claude Code, bir geliştiricinin inşa edebildiğini değiştiriyor. Ama bir geliştiricinin karar vermesi gerekenleri değiştirmiyor. Bu fark, AI destekli geliştirmenin beklentilerini doğru kalibre etmek için kritik. Araç kapasitenizi artırır; sorumluluğunuzu azaltmaz.

Beta stratejisi ve Claude Code etkisi için bkz. niranar.com Beta Stratejisi.

Beş Dersin Birleştiği Yer

Bu beş ders yüzeyde birbirinden bağımsız görünüyor — bir veritabanı kararı, bir harita seçimi, bir beta stratejisi, bir dil-para birimi gerilimi, bir geliştirme aracı analizi. Ama hepsinin altında aynı yapısal soru yatıyor: Pre-revenue, tek geliştirici, beta aşamasında bir platform için hangi ödünleşimler kabul edilebilir?

Her kararın mantığı bu soruya verilen yanıtlardan oluştu. Supabase seçimi, ölçek tavanını basitlik ve hız için kabul etmekti. Leaflet seçimi, geliştirme zamanını API maliyeti riskine karşı tercih etmekti. Auth ve ödeme yokluğu, keşif doğrulamasını işlemsel karmaşıklığa öncelendirmekti. EUR artı Türkçe gerilimi, iki kitleye tek arayüzle ulaşmaya çalışmanın kaçınılmaz maliyetiydi. Claude Code kullanımı, AI'ın yargıyı destekleyebileceğini ama yerine geçemeyeceğini öğrenmekti.

Bu kararların tümü savunulabilir ve kayıtlara geçirilmiştir. Ama savunulabilir olmak ile "bir sonraki seferde aynı kararı alırız" demek aynı şey değil. Bağlam değişirse — ekip büyürse, bütçe artar, arama kalitesi kritik bir farklılaşma noktası haline gelirse — bu kararların her biri yeniden değerlendirilebilir. Bağlamın ne olduğunu değil, bağlamın ne olduğunda bu kararları almanın mantığını belgelemek: bu serinin son yazısının asıl amacı buydu.

Pek çok vaka çalışması başarıyı anlatır. Daha azı neyin işe yaramadığını söyler. En az sayıda vaka çalışması ise neyin işe yaradığını ama bir bedelle işe yaradığını, neyin ertelendiğini ve bir sonraki aşamada hangi soruların tekrar sorulması gerektiğini açıklar. Bu üçüncü kategoriye girebilmek, ancak her tercihin neden yapıldığını dürüstçe kayıt altına almakla mümkün olur. niranar.com bu kaydı bırakmaya çalıştı.

Niranar serisi boyunca her konuya ayrıntılı bakış için: niranar.com Ürün Tanıtımı, Teknik Mimari, Veri Normalizasyonu, SEO Mimarisi ve Pazar Analizi.

Sonuç

niranar.com'un serisi ürünü her açıdan tanımlamayı amaçladı. Bu son yazı o tanımlamayı bir güven jesti olarak tamamlıyor: hangi kararların hangi bedelleri gerektirdiğini açıkça belgelemek.

Bir pazar yeri platformu kurarken mükemmel kararlar yoktur — yalnızca mevcut kısıtlara göre savunulabilir ödünleşimler vardır. Supabase bir ölçek tavanı yaratıyor. Leaflet bir zaman yatırımı gerektiriyor. Auth olmadan çalışmak sabır istiyor. İki kitleye tek arayüz hizmet vermek gerilim doğuruyor. AI kapasiteyi artırıyor ama yargıyı devralmıyor. Bunların hepsi beta aşamasında kabul edilmiş gerçek bedellerdir.

Bu dürüstlük, teknik yeterlilikten farklı bir güven kaynağıdır. Neyin işe yaradığını söylemek yeterince kolaydır; neyin maliyetli olduğunu söylemek başka bir şey gerektiriyor. Benzer sorunları çözmek isteyen ekipler için niranar.com, bu ödünleşimlerin nerede olduğunu ve hangi kararların bir sonraki aşamada yeniden tartışılması gerekebileceğini gösteriyor.