Solo kurucu için en az araçlı düzen

Yeni bir ürüne başlarken en keyifli kısım çoğu zaman araç seçmek oluyor. Hangi çerçeve, hangi veritabanı, hangi analitik servisi, hangi e-posta aracı... Bir bakıyorsun, ürünün daha ilk kullanıcısı yokken altı yedi ayrı servise üye olmuşsun.

Bu yazı sana bir araç listesi vermeyecek. Onun yerine, tek başına ürün yapan birinin başlangıçta hangi işlere ihtiyaç duyduğunu ve her yeni aracın gizli maliyetini anlatacak. Verdiğimiz isimler sadece örnek, tavsiye değil.

Dayanağımız, yazılım dünyasında çok tartışılmış iki fikir: Dan McKinley'nin "sıkıcı teknolojiyi seç" yazısı ve tek başına milyonlarca kullanıcıya ulaşan Pieter Levels gibi kurucuların bilerek sade tuttuğu düzenler.

Her araç bir borçtur

Dan McKinley, 2015'te yazdığı ve bugün hâlâ Hacker News'te sık sık yeniden tartışılan "Choose Boring Technology" yazısında "yenilik jetonu" diye bir fikir ortaya atıyor. Her şirketin, yeni ve riskli teknolojiler için harcayabileceği yaklaşık üç jetonu var. Genç bir veritabanı ya da popüler ama olgunlaşmamış bir çalışma ortamı seçtiğinde bir jeton harcıyorsun. McKinley'ye göre bu jetonları seni gerçekten farklı kılan yerde harcamalısın.

McKinley'nin asıl uyarısı şu: her yeni araç izleme, test, bakım ve zihinsel yük getiriyor. Yazısındaki cümleyle, bir sistemi uzun vadede güvenilir şekilde çalışır tutmanın maliyeti, başlangıçtaki küçük rahatsızlıkları kat kat aşıyor.

Tek başına çalışıyorsan bu yük tamamen senin sırtında. Bir ekipte her aracı başka biri izleyebilir. Sende ise her yeni servis, bir gece yarısı uyarısı ve bir aylık fatura demek.

Pieter Levels'ın "bildiğinle devam et" yaklaşımı

Pieter Levels, Lex Fridman'ın 440. bölümünde yığınını anlatıyor: büyük ölçüde sade HTML, jQuery, PHP ve SQLite. Bunu bilinçli bir manifesto olarak seçmediğini, en başta bunu bildiği için kullandığını söylüyor. Node.js öğrenmeyi düşündüğünü ama projeleri büyürken buna hiç vakit bulamadığını anlatıyor.

Levels'ın çerçevelere karşı temkininin nedeni de bakım. Çerçevelerin sık değiştiğini, bu yüzden bakımlarının zor olduğunu söylüyor. Ama çerçeveleri tamamen reddetmiyor; gerçek bir sorunu çözüyorsa kullanılmasını öneriyor.

Buradan çıkarılacak ders "PHP kullan" değil. Ders şu: zaten bildiğin araçla başla. Yeni bir dil ya da çerçeve öğrenmek bir yenilik jetonu harcamak demek. Ürünün kendisi zaten yeterince belirsiz.

Tek kişilik şirketlerin sıkıcı düzenleri

"Tek kişilik bir internet şirketinin arkasındaki sıkıcı teknoloji" başlıklı yazının HN tartışması, bu yaklaşımın sahadaki karşılığını gösteriyor. Kendisi de tek kişilik bir şirket işleten bir yorumcu, üretim sunucusunda sadece bir web sunucusu ve birkaç basit betik çalıştırdığını, sistem bakımına haftada bir saatten az zaman harcadığını yazıyor. Ona göre tek kişilik bir işi büyütürken en önemli ilke basit tutmak.

Aynı tartışmada karşı görüş de var. Bir başka yorumcu, tek kişi için kendi sunucusunu yönetmenin aslında aşırı mühendislik olabileceğini, yönetilen servislerin daha az iş çıkarabileceğini savunuyor.

Bu iki görüş çelişmiyor. İkisi de aynı soruyu soruyor: bu düzen beni ne kadar uğraştıracak? Sunucu yönetmeyi biliyorsan tek bir sunucu en basit yol olabilir. Bilmiyorsan yönetilen bir barındırma servisi daha az yük getirir.

Yapay zekâ çağında "sıkıcı" daha da değerli

McKinley'nin yazısı 2026'da HN'de yeniden tartışıldığında bir yorumcu ilginç bir noktaya değindi. Yapay zekâ ajanlarıyla çalışıyorsan, ajanların iyi bildiği, yani eğitim verisinde bol bulunan teknolojileri seçmek mantıklı. Teknik olarak biraz daha iyi bir alternatifin avantajı, ajanın o teknolojideki zayıflığı yüzünden kaybolabilir.

Yaygın, belgelenmiş ve yıllardır kullanılan araçlar hem senin hem de yapay zekâ asistanının daha az hata yapmasını sağlıyor.

"Sıkıcı" eski demek değil

Aynı 2026 tartışmasında fikre itiraz edenler de var. Bir yorumcu, "yeni" ve "eski" kelimelerinin zayıf ölçütler olduğunu, asıl sorulması gerekenin bir aracın ne kadar iyi test edildiği olduğunu savunuyor. Ona göre eski yazılımların bir kısmı da kötü test edilmiş olabilir.

Bu itiraz işine yarar. "Sıkıcı" seçimi yaparken yaşına değil, şu üç şeye bak: ne kadar yaygın kullanıldığı, sorun yaşadığında cevabını bulabileceğin kadar belgelenip belgelenmediği ve senin onu ne kadar iyi tanıdığın. Beş yıllık ama az kullanılan bir araç, on yıllık ve herkesin bildiği bir araçtan daha riskli olabilir.

Başlangıçta gerçekten neye ihtiyacın var?

İlk ücretli müşterine kadar çoğu ürün için şu kategoriler yeterli:

1. Kod ve barındırma. Kodunun durduğu bir depo ve uygulamanın çalıştığı tek bir yer. Bildiğin bir sunucu ya da yönetilen bir barındırma servisi.
2. Tek bir veritabanı. Ürünün ilk sürümü için genelde bir tane yeter. Levels'ın SQLite tercihinde olduğu gibi, ayrı bir veritabanı sunucusu gerektirmeyen seçenekler de var.
3. Ödeme alma. Türkiye'deki müşterilere satıyorsan yerel bir ödeme kuruluşu, yurt dışına satıyorsan global bir sağlayıcı. Hangisinin sana uygun olduğu şirket yapına da bağlı.
4. E-posta. Kendi alan adınla bir e-posta adresi ve uygulamanın şifre sıfırlama gibi mesajlarını gönderebileceği bir servis.
5. Basit ölçüm. Kaç kişinin geldiğini ve kaçının kaydolduğunu görebileceğin hafif bir araç.
6. Kullanıcıyla konuşma kanalı. E-posta ya da Türkiye'de çok yaygın olan WhatsApp. Ayrı bir destek yazılımına ilk aylarda gerek yok.
7. Yedek. Veritabanının otomatik ve düzenli yedeği. Bu, listede atlanmaması gereken tek kalem.

Örnek düşünelim. Eskişehir'de bir pilates stüdyosu için ders rezervasyon aracı yapan bir kurucu, bu yedi kalemle ilk on stüdyoya hizmet verebilir. Bir CRM'e, otomasyon zincirine ya da ücretli bir analitik platformuna ihtiyacı yok.

Neleri ertelemelisin?

İlk ücretli müşterilere kadar şunları bekletebilirsin:

• Birden fazla sunucuya yayılan karmaşık altyapılar ve mikroservisler.
• Ayrı bir müşteri ilişkileri yönetimi aracı. İlk 20 müşteriyi bir tabloda takip edebilirsin.
• Araçlar arası otomasyon zincirleri. Bir işi elle on kez yapmadan otomatiğe bağlama.
• Ayrıntılı ürün analitiği. Az kullanıcıyla, kullanıcılarla konuşmak daha çok şey öğretir.
• Proje yönetim araçları. Tek kişi için düz bir yapılacaklar listesi genelde yeterli.

Bunlar kötü araçlar değil. Sadece henüz çözdükleri bir sorunun yok.

Yeni bir araç eklemeden önce üç soru

McKinley yeni bir teknoloji eklemeden önce, sorunu elindekilerle çözüp çözemeyeceğini sormayı ve mevcut düzenin neden yetmediğini yazıya dökmeyi öneriyor. Bunu tek kişilik bir ürüne uyarlarsak üç soru çıkıyor:

1. Bu sorunu zaten kullandığım bir araçla çözebilir miyim? Çoğu zaman cevap evet.
2. Bu aracın bana ne kazandıracağını tek cümleyle yazabilir miyim? Yazamıyorsan muhtemelen ihtiyacın yok.
3. Bu araç bozulursa ya da fiyatını artırırsa ne olur? Türkiye'den dolarla abonelik ödüyorsan, kur değişimi de bu sorunun parçası.

DHH, Rails 7'yi "tek kişilik çerçeve" olarak tanıttığı 2021 yazısında "kavramsal sıkıştırma"dan söz ediyor: araç, ayrıntıları saklayarak tek bir geliştiricinin daha az şey öğrenip daha hızlı ürün çıkarmasını sağlıyor. Hangi aracı seçersen seç, amaç aynı olmalı: aklında tutman gereken parça sayısını azaltmak.

Abonelikleri her ay gözden geçir

Araç sayısı zamanla sessizce artar. Ayda bir, kartından çekilen bütün abonelikleri listele. Son 30 günde kullanmadığın ya da ne işe yaradığını tek cümleyle açıklayamadığın aracı iptal et. Ücretsiz katmanı olan araçlarda, ücretli plana ne zaman geçeceğini önceden bir kullanıcı ya da gelir eşiğine bağla.

Bu hafta yapılacak

1. Şu an kullandığın tüm araçları ve aylık maliyetlerini, döviz olanları ayrı işaretleyerek tek bir listeye yaz.
2. Listeyi yukarıdaki yedi kategoriyle karşılaştır. Hiçbir kategoriye girmeyenleri işaretle.
3. İşaretlediklerin için üç soruyu sor ve en az birini iptal et.
4. Veritabanı yedeğinin gerçekten alındığını kontrol et. Bir yedeği geri yüklemeyi bir kez dene.
5. Yeni bir araç ihtiyacı doğduğunda önce bir "bekleyen araçlar" listesine yazma kuralı koy.

Sık sorulanlar

Popüler yeni bir çerçeveyi öğrenmek istiyorum, hata mı?

Öğrenmek hata değil. Ama ilk ürününü aynı anda hem yeni bir çerçeveyle hem de belirsiz bir pazarda yapmak iki riski birden almak demek. McKinley'nin diliyle bir yenilik jetonu harcıyorsun. Bunu bilerek yap.

Kod yazmadan çalışan araçlar da bu yaklaşıma uyar mı?

Uyar. Aynı mantık geçerli: az parça, bildiğin araçlar ve kolay yedek. Sadece verini dışarı aktarıp aktaramadığını baştan kontrol et.

Ücretsiz katman varken neden araç sayısını sınırlayayım?

Çünkü maliyet sadece para değil. Her araç ayrı bir giriş, ayrı bir ayar, ayrı bir olası arıza noktası. Tek başına çalışan biri için asıl kıt kaynak dikkat.

Ne zaman daha karmaşık bir altyapıya geçmeliyim?

Mevcut düzenin somut bir sorun çıkardığında. Örneğin sistem yavaşlıyor ve kullanıcılar şikâyet ediyorsa. "İleride büyürsem" diye önceden kurma.

Dayanak

• Choose Boring Technology — Dan McKinley: Yenilik jetonları, her yeni teknolojinin bakım maliyeti ve araç eklemeden önce sorulacaklar.
• Choose Boring Technology (2015) — Hacker News tartışması, 2026: Yapay zekâ ajanlarının iyi bildiği teknolojileri seçme yorumu.
• The boring technology behind a one-person Internet company — Hacker News tartışması: Haftada bir saatten az bakım isteyen tek kişilik düzen ve yönetilen servis karşı görüşü.
• Pieter Levels transcript — Lex Fridman Podcast #440: Sade PHP, jQuery ve SQLite yığını, bildiğinle devam etme ve çerçevelerin bakım yükü.
• The One Person Framework — DHH: Tek geliştiricinin daha az şey öğrenerek ürün çıkarmasını sağlayan kavramsal sıkıştırma.