Aylık 20 dolarlık bir stack ile aylık geliri 10 bin dolar olan birden fazla şirket nasıl işletilir

 (stevehanov.ca)
63 puan yazan GN⁺ 17 일 전 | 1 yorum | WhatsApp'ta paylaş
  • Tek bir VPS, Go dili, SQLite ve yerel GPU kullanarak aylık 20 doların altında altyapı maliyetiyle MRR’si 10 bin doların üzerinde olan birden fazla SaaS şirketi işletmeye yönelik bootstrap stratejisi
  • AWS veya karmaşık bulut orkestrasyonu yerine 5–10 dolarlık tek bir VPS üzerinde tüm servisleri çalıştırıp, altyapı yönetimi yerine istek işlemeye odaklanma
  • Arka uç dili olarak Go seçilerek, bağımlılık yönetimine gerek kalmadan tek bir binary olarak derleyip sunucuya dağıtılan son derece basit bir deployment süreci elde etme
  • Yerel GPU’da (RTX 3090) VLLM çalıştırarak yapay zeka batch işleme maliyetini sıfıra indirme, yalnızca kullanıcıya dönük özelliklerde OpenRouter üzerinden frontier modelleri kullanma
  • Venture capital olmadan da maliyetleri neredeyse sıfırda tutarak fiilen sınırsız runway elde etmenin ve ürün-pazar uyumunu bulmak için yeterli zamanı kazanmanın mümkün olması

Yalın sunucu işletim stratejisi

  • 2026’da bir web uygulaması yayınlamanın yaygın yolu AWS üzerinde EKS cluster, RDS instance ve NAT Gateway provision etmek; bu da daha tek bir kullanıcı yokken bile ayda 300 doların üzerinde harcama anlamına geliyor
  • Alternatif olarak Linode veya DigitalOcean üzerinden aylık 5–10 dolarlık bir VPS kiralayıp tek sunucuyla çalışmak
  • 1GB RAM bile doğru kullanılırsa yeterli olabilir; biraz esneklik gerekirse swapfile kullanılabilir
  • Tek bir sunucu olduğunda logların nerede olduğunu, çökme nedenini ve nasıl yeniden başlatılacağını tam olarak bilmek mümkün
  • AWS yerine VPS seçmenin nedeni öngörülebilir maliyetler ve basit bir mimariyi korumak

Neden Go dili seçiliyor?

  • Python veya Ruby, yalnızca interpreter açılışı ve gunicorn worker yönetimi ile RAM’in yarısını tüketebiliyor
  • Go, web işlerinde çok daha yüksek performans sunuyor, katı bir tip sistemine sahip ve 2026 itibarıyla LLM’lerin muhakeme yürütmesi çok kolay bir dil
  • Go’nun temel avantajı deployment sürecinin sadeliği: tüm uygulamayı tek bir statik bağlı binary olarak derleyip dizüstünde build ettikten sonra scp ile sunucuya aktarıp çalıştırmak
  • pip install bağımlılık cehennemine veya sanal ortamlara gerek yok; şişkin framework’ler olmadan da production seviyesinde web sunucusu kurmak mümkün
  • Sadece Go standart kütüphanesiyle saniyede on binlerce isteği işleyebilen sunucular yazılabilir

Yerel yapay zeka kullanımı: batch işlerin maliyetini sıfırlamak

  • Evde bir ekran kartınız varsa zaten sınırsız yapay zeka kredisine sahip sayılırsınız
  • eh-trade.ca inşa edilirken binlerce şirketin çeyreklik raporlarını analiz eden büyük ölçekli niteliksel hisse araştırması gerekiyordu; OpenAI API kullanılsaydı bunun maliyeti yüzlerce dolara çıkabilirdi
  • Bunun yerine Facebook Marketplace’ten 900 dolara alınan RTX 3090 (24GB VRAM) üzerinde VLLM çalıştırılarak yapay zeka sağlayıcılarına ödeme yapma ihtiyacı ortadan kaldırıldı
  • Yerel yapay zeka için yükseltme yolu:
    • Ollama ile başlamak: tek satırlık bir komutla (ollama run qwen3:32b) kurulum yapmak, farklı modelleri anında denemek ve prompt iterasyonu için ideal olmak
    • Production’a VLLM ile geçmek: Ollama eşzamanlı isteklerde darboğaz yaratırken, VLLM PagedAttention kullanarak dramatik biçimde hızlanır. Aynı anda 8–16 asenkron istek gönderildiğinde, bunlar GPU belleğinde batch işlenir ve neredeyse tek bir isteğin süresi kadar zamanda tamamlanır
    • Transformer Lab: model pretraining veya fine-tuning gerektiğinde bunu yerel donanımda kolayca yapmak
  • Bunu yönetmek için geliştirilen şirket içi araç laconic: 8K context window’a optimize edilmiş bir ajan araştırma aracı; işletim sisteminin sanal bellek yöneticisi gibi konuşmanın gereksiz kısımlarını “page out” ederek yalnızca temel gerçekleri aktif LLM context’inde tutuyor
  • llmhub: tüm LLM’leri provider/endpoint/apikey kombinasyonuyla soyutlayıp, metin ve görsel G/Ç’yi ister yerelde ister bulutta sorunsuz biçimde yöneten araç

OpenRouter üzerinden frontier modellere erişim

  • Her işi yerelde halletmek mümkün değil; kullanıcıya dönük düşük gecikmeli sohbet etkileşimleri için Claude 3.5 Sonnet veya GPT-4o gibi en ileri muhakeme modelleri gerekiyor
  • Anthropic, Google ve OpenAI için ayrı ayrı billing hesabı, API anahtarı ve hız limiti yönetmek yerine her şeyi OpenRouter altında birleştirmek
  • OpenAI uyumlu tek bir entegrasyon kodu yazınca tüm büyük frontier modellere anında erişim sağlanabiliyor
  • Sorunsuz fallback routing desteği var: Anthropic API arızalanırsa sistem otomatik olarak eşdeğer bir OpenAI modeline geçiyor; kullanıcı hiç hata ekranı görmüyor ve karmaşık retry mantığına gerek kalmıyor

GitHub Copilot ile maliyet verimli yapay zeka kodlama

  • Her hafta yeni pahalı modeller çıkarken, geliştiriciler Cursor aboneliği ve Anthropic API anahtarları için ayda yüzlerce dolar harcıyor
  • Buna karşılık Claude Opus 4.6 tüm gün kullanılsa bile aylık maliyet neredeyse hiç 60 doları geçmiyor
  • İşin püf noktası Microsoft’un fiyatlandırma modelinden yararlanmak: 2023’te GitHub Copilot aboneliği satın alıp bunu standart VS Code’a bağlamak
  • Copilot’ın kilit hilesi şu: Microsoft token başına değil, istek başına ücret alıyor ve “istek”, sohbet kutusuna girilen tek bir içerik anlamına geliyor. Ajan 30 dakika boyunca tüm kod tabanını analiz edip yüzlerce dosyayı değiştirse bile maliyet yaklaşık 0.04 dolar oluyor
  • En iyi strateji: net başarı kriterleri içeren ayrıntılı bir prompt yazmak, ardından “tüm hatalar düzeltilene kadar devam et” talimatını verip çalıştırmak

Tüm veritabanı ihtiyaçlarında SQLite kullanmak

  • Yeni bir girişime başlarken ana veritabanı olarak her zaman sqlite3 kullanılıyor
  • Kurumsal bakış açısında ayrı bir süreçte çalışan veritabanı sunucusu gerektiği düşünülse de, pratikte C arayüzü veya bellek üzerinden iletişim kuran yerel bir SQLite dosyası, TCP üzerinden ağ sıçraması yaparak erişilen uzak bir Postgres sunucusundan birkaç büyüklük mertebesi daha hızlı
  • Eşzamanlılık sorunlarına dair yanlış kanı: SQLite’ın her yazma işleminde tüm veritabanını kilitlediği düşüncesi doğru değil; bu, Write-Ahead Logging(WAL) etkinleştirilerek çözülebilir
    • PRAGMA journal_mode=WAL; ve PRAGMA synchronous=NORMAL; ayarlarıyla okuma ve yazma işlemleri birbirini engellemez
    • NVMe sürücüsündeki tek bir .db dosyasıyla binlerce eşzamanlı kullanıcıyı desteklemek mümkün
  • Kullanıcı kimlik doğrulamasını kolay uygulamak için geliştirilen şirket içi kütüphane smhanov/auth: kullanılan veritabanıyla doğrudan entegre oluyor ve kayıt, oturum, şifre sıfırlama, Google/Facebook/X/SAML ile giriş desteği sunuyor

Sonuç: karmaşık altyapı olmadan startup kurmak

  • Teknoloji sektörü, gerçek bir iş kurmak için karmaşık orkestrasyon, yüksek aylık AWS faturaları ve milyonlarca dolarlık venture capital gerektiğini öne sürüyor; ama durum böyle değil
  • Tek VPS, statik derlenmiş binary’ler, yerel GPU donanımıyla yapılan batch yapay zeka işleri ve SQLite’ın ham hızını birleştirince, aylık birkaç kahve parasına ölçeklenebilir bir startup bootstrap etmek mümkün
  • Bu yaklaşım projeye sınırsız runway kazandırıyor; böylece burn rate kaygısı yerine kullanıcı sorunlarını çözmeye odaklanacak zaman kalıyor

İlgili okumalar

1 yorum

 
GN⁺ 17 일 전
Hacker News görüşleri

  • Kurumsal ortamlarda harici DB sunucusu kullanmak gerektiğine dair güçlü bir algı var; ancak gerçekte yerel SQLite dosyası, C arayüzü ya da bellek üzerinden iletişim kurduğunda uzak bir Postgres'ten çok daha hızlıdır
    Elbette SQLite harika, ama Postgres'e localhost üzerinden Unix domain socket ile bağlanırsanız ağ ek yükünü neredeyse tamamen ortadan kaldırabilirsiniz
    SQLite'tan daha zor kullanılması gerekmez, Postgres'in tüm özelliklerinden yararlanabilirsiniz ve rapor çalıştırma ya da read replica kurma, HA yapılandırması da çok daha kolaydır
    Postgres'i uygulamayla aynı sunucuda çalıştırmak, Kubernetes kümesi kurmak gibi aşırı hazırlıkla aynı düzeyde bir tercih değildir

    • Aynı makinede bile SQLite, domain socket kullanan Postgres'ten çok daha hızlıdır (100.000 TPS örneği)
      Tek bir makinede monolithic app çalıştırırken Postgres'in SQLite'a göre sunduğu özellikler çok fazla değildir
      SQLite, Application functions ile doğrudan uygulama dili içinde genişletilebilir ve Litestream sayesinde yedekleme ile replikasyon da çok daha iyi hale gelir
      Ancak varsayılan ayarları iyi değildir; okuma/yazma bağlantılarını ayırmak ve uygulamanın write queue'yu doğrudan yönetmesi gerekir
    • Gerçekte 100.000 kez SELECT 1 sorgusu çalıştırıldığında Postgres 2,77 saniye, SQLite (in-memory) ise 0,07 saniye sürüyor; arada büyük fark var (benchmark bağlantısı)
    • Milyonlarca belgeyi saniyede işleyen yüksek performanslı senaryolarda SQLite'ı eklentilerle birlikte kullandım
      Uzak sunucuyla da yapılabilirdi ama çok daha karmaşık olurdu
      Onun yerine DB'yi S3'e koyup her instance'ın bir kopya alarak paralel işlemesini sağladım. SQLite, özellikten çok performansa ihtiyaç duyulan durumlarda kanıtlanmış bir alternatiftir
    • “Postgres'in tüm özelliklerini kullanabilirsiniz” sözü, tam da TFA'nın eleştirdiği YAGNI (You Ain’t Gonna Need It) yaklaşımı değil mi?
    • Gerekli olmayan özellik ne kadar fazlaysa o kadar net kayıp demektir. İdeal DB yalnızca gereken özellikleri sunar

  • Birçok kişi en baştan serverless, Kubernetes, multi-zone HA gibi karmaşık kurulumlar gerektiğine inanıyor
    “Ucuz bir VPS üzerinde çalıştırmak da yeter” denince “Peki ölçekleme?”, “Yedekleme?”, “Bakım?” gibi tepkiler geliyor; oysa bu fiilen bulut pazarlama söylemini tekrarlamak demek
    Bu tavır, öğrenilmiş çaresizliğe yakın

    • Danışman olarak çalışırken, 200'den az kullanıcısı olacak bir uygulama için 25 bulut bileşeni tasarladığım oluyordu. Hepsi de “bulut = karmaşık olmalı” eğitiminin sonucuydu
    • IT satın alma ekipleri, anlamak zorunda kalmamaları için şirket parasını cömertçe harcıyor
    • Bugünlerde aynı durumu ajan tabanlı workflow tarafında da görüyorum. Eğitim verileri büyük ekipler için yazılmış devasa kod tabanlarıyla dolu olduğu için, küçük projeler bile büyük yapılara yönlendiriliyor
      Örneğin birkaç basit giriş formundan oluşan bir SPA'ya Shadcn, Tailwind, React, Zod ve Vite'ın hepsini birden koymak gibi. Bunun bakım yükü çok büyük
      Böyle bir kurulum “doğru cevap” olabilir ama duruma uygun cevap değildir
    • “Cloud-native nesli”, ücretsiz planlar sayesinde temel bir uygulamanın gerçekte neye ihtiyaç duyduğunu öğrenme fırsatı bulamadı
    • Yine de yedeklemenin önemli olduğunu düşünüyorum

  • Linode ya da DigitalOcean kullanıyorum ve ayda sadece 5-10 dolar ödüyorum. 1GB RAM yeterli oluyor
    Birden fazla projeyi tek bir dedicated server üzerinde toplarsanız maliyeti daha da düşürebilirsiniz
    Örneğin Hetzner server auction üzerinden aylık 40 euroya bir sunucu kullanıyorum, üzerine Proxmox kurup birden çok VM çalıştırıyorum (Proxmox bağlantısı)
    15 VM oluştursanız bile VM başına 2,66 euro seviyesine geliyor; yani ölçeğe göre maliyet verimliliği çok yüksek
    Yenilenmiş donanım kullanıyorsanız yedek şart, ama zaten yapılması gereken bir iş
    Hetzner, Contabo ve Scaleway gibi yerler hâlâ ucuz seçenekler

    • Hetzner fiyatları artmış olsa da OVH benzer fiyata daha yeni donanım sunuyor
    • Neden VM kullanıp container kullanmadığını merak ediyorum
    • IPv4'ü nasıl yönettiğini de merak ediyorum. Hypervisor olarak büyük bir VM kiralamanın ticari olarak izinli olup olmadığı da soru işareti
    • Sadece Docker container ile çalıştırmak daha verimli olmaz mı?

  • SQLite'ın WAL modu en büyük maliyet düşürücü etken bence
    Python ya da Node da Go kadar rahat kullanılabilir. Hetzner'de 4GB RAM ve 10TB ağ trafiği sunan VPS aylık 5 dolar civarında
    Ancak dedicated server kullanıyorsanız DB yedeklerini sık almanız ve güvenlikten bizzat sorumlu olmanız gerekir
    Ben Terraform ile SSH erişimini yalnızca kendi IP'me kısıtlıyor, Tailscale kurduktan sonra da herkese açık SSH portunu kapatıyorum

    • Yedekler için VM sağlayıcısından farklı bir şirketin depolamasını kullanmak daha güvenli. Hesabınız askıya alınsa bile geri dönebilmeniz gerekir
      Ben Backblaze B2 kullanıyorum ama Restic ile başka servislere de kolayca yedek alınabiliyor
    • SSH güvenliği için mutlaka karmaşık bir ayar gerekmiyor. Güçlü bir parola bile yeterli olabilir
    • Eskiden Postgres'i varsayılan parolayla açık bırakmıştım ve bir gün içinde bot sunucusuna dönüştürülerek hacklenmişti
      Yakın zamanda da SSH deneme loglarının bir saat içinde dolduğunu gördüm. Artık parola ile girişi kapatıp yalnızca Tailscale üzerinden erişiyorum
      İnternete açık sunucular gerçekten tehlikeli
    • SSH üzerinden bir saatte enfekte olunması bana inandırıcı gelmiyor. Zayıf bir parola ya da açık bir VNC yoksa bu mümkün görünmüyor
    • Ben de Django sitemi Docker Compose'a taşırken Postgres'ten vazgeçip SQLite WAL'a geçtim. Yönetim ve yedekleme çok daha basit hale geldi

  • 1GB RAM sınırının gereksiz olduğunu düşünüyorum. Ayda 20 dolara 8GB RAM alabilirsiniz; bunu cache ya da DB için kullanmak mümkün
    15 dolarlık fark bir işi yürütürken büyük etki yaratmaz. 5 dolarlık VPS'e sığma düşüncesi işinizi büyütmeye yardımcı olmaz

    • Ama 15 dolar da önemsiz para değil. 1GB yetiyorsa daha fazlasını harcamaya gerek yok
      Eskiden 128MB ile bile LAMP stack gayet iyi çalışıyordu ve bugün de web siteleri o kadar karmaşık değil
    • NVMe okuma gecikmesi 100µs civarında olduğundan SQLite ile saniyede yüzlerce istek karşılanabilir
      Cache olmadan bile günde 17 milyon istek kaldırılabiliyorsa, daha buna ihtiyaç doğmadan altyapıyı 4 kat büyütmek israftır
    • 1GB sınırının asıl nedeni, aşırı mühendislikten kaçınıp müşteri değerine odaklanma alışkanlığı kazanmaktır
    • Modern sistemler, sayfa sıkıştırma ve NVMe swap sayesinde RAM'i çok daha verimli kullanıyor
      Bunun iyi bir örneği 8GB'lık Macbook Neo modeli
    • Ben de 15 dolarlık farkın çok büyük olmadığını düşünüyorum ama asıl mesele hosting maliyetini minimumda tutmak

  • WebSequenceDiagram güzel bir ürün gibi görünüyor
    Ama teknik uygulamadan daha zor olan şey, değerli bir problem bulmak ve kullanıcılara ulaşmak. Asıl değer orada

    • Ben de aynı konuyu düşünüyorum. İş ve aile derken gün yetmiyor. Ama belirli bir alan problemine denk gelince çözüm çok bariz görünebiliyor
    • Zaten çok sayıda rakip ürün var. Örneğin Excalidraw gibi

  • 2023'te GitHub Copilot aboneliği aldım, VS Code'a bağladım ve o zamandan beri kullanıyorum
    Buradaki kilit nokta, Microsoft'un istek başına ücretlendirme yapması. Tek bir istekle onlarca dakika boyunca tüm kodu düzenletse bile yaklaşık 0,04 dolar ödüyorum
    Bu yüzden çok ayrıntılı prompt'lar yazıyor, “tüm hatalar çözülene kadar devam et” diyorum ve gidip kahve alıyorum. Adeta Satya Nadella benim hesaplama maliyetimi sübvanse ediyor

    • Ama bu tür istek bazlı kötüye kullanım nedeniyle hesabı kapatılan örnekler var (Reddit örneği)
    • Yazarın GPT‑4o ve Sonnet 3.5'i SOTA diye anması nedeniyle, AI ipuçlarına biraz şüpheyle yaklaşmak iyi olabilir
    • (silinmiş yorum) Neden downvote aldığını anlamadığını söylüyor

  • Yazıda benim için yeni bir şey yoktu. Çoğu, temel tavsiyelerin AI tarafından cilalanmış hali gibiydi
    Başlığa bakınca fikir bulma ve başarılı lansman üzerine olacağını sanmıştım

    • “Aylık 5 doların altında” gibi bir başlık varsa temel tavsiyeler çıkması normal. Yine de şaşırtıcı biçimde bunları bilmeyen çok kişi var
    • O zaman blog yazmaya başlamanı öneririm. Senin temel gördüğün bilgi, başkası için yeni olabilir
    • Ben de ayda 5 bin dolar harcayıp 10 bin dolar kazanabileceksem memnuniyetle yaparım. Sorun, gelir yaratmanın yolunu bulmakta
    • “Claude 3.5 Sonnet veya GPT‑4o'nun son teknoloji muhakemesine ihtiyacınız var” cümlesi, AI ile yazılmış metinlerin izi gibi duruyor
    • Ama yazarın söz ettiği kaynak enflasyonu gerçekten var. Basit bir Python scriptiyle çözülebilecek işleri AWS ve Spark ile gereğinden fazla karmaşıklaştıran örnekleri sık görüyorum

  • Benim gibi merak edenler için, MRR “Monthly Recurring Revenue” yani “aylık tekrarlayan gelir” anlamına geliyor

    • 16 yıl önce üye olmuş birinin MRR'yi bilmemesine şaşırdım
    • ARR (Annual Recurring Revenue) de var ama çoğu zaman MRR'nin sadece 12 ile çarpılıp şişirilmiş hâli oluyor
      İki aydır çalışan bir iş için ARR açıklayan insanlar bile gördüm

  • Bulut merkezli düşünme, birçok durumda karmaşıklığı ve maliyeti gereksiz yere artırıyor
    Çoğu proje için orta ölçekli bir VPS fazlasıyla yeterli
    Şirketimiz 600 bin kullanıcı sayfasını 30 euroluk bir VPS üzerinde çalıştırabiliyordu; AWS'ye geçince ayda 800 euro ödemeye başladık. Hiçbir kazanç olmadı
    Bunun için özel bir neden yoksa, onlarca yıldır iyi çalışan basit sunucu yaklaşımını sürdürmek en iyisi
    Bu arada StackOverflow'un da güçlü birkaç root server ile çalıştığını duymuştum