- Tüm hizmeti tek başına Rails ile geliştirip bakımını yaparak, yıllık 1 milyon euro ARR'ye (yinelenen gelir) ulaşan bir solo geliştiricinin sahadan deneyimleri
- Başlangıçta yalnızca temel bir MVP ile yola çıkıldı, ancak tam yeniden yazım ve yapısal iyileştirmeler sayesinde sürdürülebilir bir mimariye dönüştürüldü
- Kilit nokta, Rails'in tutarlı felsefesi, bileşenleri ve Turbo Native üzerinden mobil desteği sağlayabilmesi
- Tüm trafik ve kullanım yükünü karşılayıp yine de aylık 1.500 euro altı sunucu maliyetiyle çalıştırılabilen verimli bir yapı
- Sonunda uzun vadeli düşünen bir yatırımcıya hisselerin bir kısmı satıldı ve 14 yılın ardından ikinci geliştirici işe alınarak yeni bir döneme girildi
The One-Person Framework'in Pratikte Uygulanışı
Yalnızca Rails ile 1 milyon euro ARR'ye ulaşmak
- 2022'nin başında PlanGo, yıllık yinelenen gelirde (ARR) 1 milyon euroyu aştı; bu, tek bir Rails kod tabanı ve tek bir geliştiriciyle yürütülen bir hizmet için adeta rüya gibi bir başarıydı
- Teknoloji dışındaki tüm alanlar — vizyon oluşturma, müşteri kazanımı, büyüme stratejisi — kurucu ortak ve müşteri destek ekibi tarafından yürütülse de, mimari tasarımdan dağıtıma, operasyondan front-end/back-end geliştirmeye kadar her şeyi tek başına üstlendi
- DHH'nin öne sürdüğü “One Person Framework”, yani bir geliştiricinin tüm uygulamayı yönetebileceği yapı, teoriden ibaret değil, gerçek hayatta doğrulanmış oldu
- Rails'in yapısal felsefesi — veritabanı tasarımı, iş mantığı ve front-end arayüzünü tek bir tutarlı araç seti içinde ele alabilmesi — özellikle küçük ekipler veya solo girişimciler için çok avantajlı
- Bu yazı şu kişiler için kaleme alındı:
- Rails geliştiricileri: Günümüzde de tek başına büyük bir ürün geliştirmenin mümkün olup olmadığını düşünenler
- Teknoloji girişimcileri: Birden çok rolü aynı anda üstlenip bunun yükünü hissedenler
- Zanaatkârlık anlayışına ve teknoloji seçimine önem verenler
Başlangıçtaki durum
- Yazar, 2011'de 21 yaşında bir geliştiriciyken mevcut PHP(CodeIgniter) projeleri üzerinde çalışırken Rails'e adım attı
- Büyük bir strateji yoktu; başlangıç noktası sadece trendi takip edip Rails denemek istemek gibi basit bir motivasyondu
- Kurucu ortağın pazarlama fikriyle, lansman haftasında kaydolanlara 1 yıl ücretsiz kullanım sunan bir teklif uygulandı
- Birkaç düzine kişi bekleniyordu, ancak gerçekte ilk haftada 500'den fazla kişi kayıt oldu
- Ürün MVP seviyesinde olduğu için kısa süre içinde yüzlerce özellik talebi, soru ve destek isteği yağmaya başladı
- Sunucular iyi çalışıyordu, fakat ürün henüz tamamlanmadan müşteri talepleri patladı
- İki kurucu ortağın da ayrı tam zamanlı işleri olduğu için buna tam zamanlı yanıt vermeleri mümkün değildi
- Sonuç olarak birçok erken dönem kullanıcıyı hayal kırıklığına uğratmak kaçınılmaz oldu
- Bu deneyim, “yazılım geliştirmek” ile “yazılım işini işletmek” arasında tamamen farklı bir problem alanı olduğunu açıkça gösterdi
- Sadece özellik geliştirmek yetmiyordu; sürdürülebilir müşteri iletişimi, beklenti yönetimi ve hizmet operasyonları sistemi gerektiği dersi çıkarıldı
Yaparken öğrenmek
- Rails eğitimleri ve Stack Overflow'a bakarak geliştirmeye başlasa da, gerçek müşterilerin iş süreçlerini taşıyan bir üretim uygulaması kurmak bambaşka bir ölçekti
- İlk dönem Rails kodunda şu tipik acemi hataları vardı:
- 200 satırı aşan controller metotları
- Sorumlulukları birbirine karışmış devasa modeller
- Verimsiz SQL sorguları
- Test kodunun olmaması
- Yapılandırma değerleri ve gizli anahtarların Git'e commit edilmesi
- Özellik geliştirmek mümkündü, ancak tüm uygulama geçici çözümlere ve kırılgan bir yapıya dayanıyordu
- Kullanıcı kimlik doğrulama, dosya yükleme, PDF üretimi, yönetici arayüzü, e-posta işleme gibi pek çok özellik Gem'lere dayanarak hızlıca geliştirildi, ancak zamanla her Gem yeni karmaşıklıklar ve sorunlar doğurdu
.round(2) kullanıldığında beklenenden farklı olarak "banker's rounding" uygulanması nedeniyle tutar hesaplama hataları yaşandı
- Basit hesaplamaları bile dış Gem'lere bırakmanın sonucu olarak, sayı işlemenin temellerini yeterince anlamamaktan kaynaklanan sorunlar ortaya çıktı
- 2013 civarında ürün işletme deneyimi arttıkça aynı anda teknik borç da hızla büyüdü ve yeni özellik geliştirmek giderek zorlaştı
Baştan yazım
- Tam yeniden yazım (Full Rewrite) genelde riskli ve verimsiz bir tercih olarak görülse de, 2014'te Rails 4 tabanında her şeyi sıfırdan yeniden kurmaya karar verildi
- Mevcut uygulamayı ayakta tutarken aynı anda yeni kod tabanını geliştirmek anlamına gelen yoğun çalışma aylar boyunca paralel yürütüldü
- Mimari sadeleştirildi, Gem bağımlılıkları yarıdan fazla azaltıldı ve çekirdek işlevlere testler eklendi
- Yeni yapı, eskisine göre daha yalın ve daha hızlıydı; özellikle de yarı zamanlı tek bir geliştiricinin bakımını yapabileceği düzeyde tasarlandı
- Bu yeniden yazım, sonrasında 10 yılı aşkın süre boyunca tek geliştiriciyle işletilebilecek teknik temel haline geldi
Rails bir süper güç
- PlanGo, 2025'e kadar yalnızca tek bir geliştirici tarafından işletildi ve bunu mümkün kılan temel unsur Rails oldu
- Convention over Configuration, entegre testler, ActiveRecord, ActiveStorage, ActiveJob gibi Rails'in yapısal özellikleri sayesinde özde olmayan kararları en aza indirip asıl değer üretimine odaklanmak mümkün oldu
- Turbolinks ve ardından Hotwire'ın benimsenmesiyle, karmaşık JS framework'leri olmadan da modern bir UI geliştirmek mümkün hale geldi
- 2011'de ilk geliştirme döneminde mobil uygulama talebi neredeyse yoktu, ancak sonrasında iOS/Android uygulamaları PlanGo'nun ana arayüzü haline geldi
- Titanium, RubyMotion, Objective-C gibi çeşitli framework'ler denenirken kalite ile hız arasındaki denge sorunu yaşandı
- Turbo Native'in benimsenmesinden sonra verimlilik keskin biçimde arttı ve temel düzeyde native geliştirme bilgisiyle bile Rails kod tabanını kullanarak yüksek kaliteli uygulamalar geliştirmek mümkün oldu
- Bu yaklaşım özellikle B2B veya SaaS uygulamalarında ideal bir yöntem; native performans ve deneyimi küçük geliştirme maliyetleriyle sağlayabiliyor
- Sonuç olarak yılda 100 binden fazla uygulama indirmesi elde edildi ve bir dönem Hollanda App Store'da Duolingo'nun üstünde yer aldı
- Tüm uygulamalar tek bir Rails geliştiricisi tarafından geliştirildi ve bakım gördü
- Başlıca metrikler:
- Ruby kodu: 36,170 satır
- JavaScript kodu: 13,495 satır
- Test kapsamı: %40
- Günlük aktif kullanıcı: 6,332
- Yoğun saatlerde dakika başına istek sayısı: 7,000
- Aylık sunucu işletme maliyeti: €1,500'ün altında
- Yapılandırılmış monolitik mimariyi korumak en iyi kararlardan biriydi; mikroservis karmaşıklığı olmadan Capistrano ile kolay deployment ve rahat debugging sağlandı
- Teknoloji girişimcileri için Rails sadece bir framework değil, tek bir kişinin tüm bir ekibin yaptığı işi yapabilmesini sağlayan bir süper güç
1 milyon euronun ötesi
- 2022'nin sonunda beklenmedik bir dönüm noktası geldi. Yurt dışından bir yatırımcı PlanGo'ya ilgi gösterip satın alma teklifini iletti
- O sırada PlanGo, bootstrapped biçimde €1M ARR'yi aşmıştı ve dış finansman olmadan da sürdürülebilir gelir yapısını ve verimli operasyonlarını koruyordu
- Bu teklif, ekip içinde "Biz bundan sonra ne istiyoruz?" sorusunu gündeme getiren bir vesile oldu
- Mevcut düzenin sürdürülmesi, dış kaynakla ölçeklenme ya da tamamen satış gibi farklı seçenekler değerlendirildi
- İşe olan bağlılık hâlâ çok güçlüydü, ancak daha fazla kaynak ve uzmanlıkla fırsatların daha kolay hayata geçirilebileceği fikri oluştu
- Nakit realize etme açısından da, 10 yılı aşkın sürede biriken değerin bir kısmını geri alırken işi büyütmeye devam etmek makul bir seçenekti
- Nihai tercih, değerleri ve uzun vadeli yönelimi uyuşan Hollandalı bir evergreen fund ile ortaklık kurmak oldu
- Hisselerin bir kısmı satıldı, ancak yönetim kontrolü ve çoğunluk hissesi korundu
- Böylece ek kaynaklar sağlanırken mevcut yapı ve kültür zarar görmedi
- Bu karar, kısa vadeli bir exit ya da agresif büyümeden ziyade, sürdürülebilir ve müşteri odaklı bir iş modeline dayanan istikrarlı büyüme stratejisinin parçasıydı
- Sonrasında da Rails tabanlı yaklaşım aynen korunurken, daha önce takip edilmesi zor olan fırsatlar daha aktif biçimde değerlendirilmeye başlandı
Öğrenilenler
- PlanGo'yu 14 yıl boyunca tek kişilik teknik girişim olarak işletirken çıkarılan dersler şunlar oldu
- Embrace Rails conventions
- Rails'in felsefesine ve kurallarına karşı koymamaya çalışmak önemli
- “Rails Way”, zaten doğrulanmış problem çözme yöntemleri sunuyor ve buna uydukça ürünün kendine özgü değerine daha çok odaklanılabiliyor
- Less is more
- Gem'ler veya JS kütüphaneleri özellikleri hızlı sunabilir, ancak aynı zamanda karmaşıklığı ve bozulma ihtimalini de artırır
- Yeni bir bağımlılık eklemeden önce mutlaka "Buna gerçekten ihtiyacım var mı?" diye sormak gerekir
- Find a community
- Solo geliştiriciler için diğer Rails geliştiricileriyle bağlantı kurmak çok önemlidir
- Örneğin Spina CMS'i geliştirirken edinilen topluluk, iş arkadaşı olmasa bile bilgi paylaşımı ve geri bildirim için değerli bir bağ işlevi gördü
- Technical debt isn't always bad
- Pazara hızlı çıkmayı sağlayan pragmatik tercihler, bazen teknik mükemmellikten daha iyi olabilir
- Teknik borçta önemli olan, onu ne zaman bilinçli olarak üstleneceğini ve ne zaman geri ödeyeceğini ayırt etmektir
- You can go far alone
- Rails sayesinde tek bir geliştirici bile ekip ölçeğinde bir ürünü tasarlayabilir, büyütebilir ve dağıtabilir
- “Mutlaka bir ekip gerekir” şeklindeki yaygın kabule bağlı kalmak zorunda değilsiniz
Bundan sonrası
- Yeni yatırım ortağı, PlanGo'nun yalın çalışma biçimini desteklerken tek bir şart öne sürdü: bir Rails geliştiricisi daha eklenmesi
- Sorun, tek kişi geliştirmenin inatla sürdürülmesi değil, 14 yılda evrilmiş bu kod tabanına yeni bir geliştiriciyi onboard etmenin kendine özgü zorluğuydu
- Kod tabanı yalnızca PlanGo'nun evrimi değil, aynı zamanda acemilikten ustalığa ilerleyen kişisel geliştirici geçmişinin de doğrudan yansımasıydı ve
farklı dönemlerdeki kendi kararlarının ve kod stillerinin bir arada bulunduğu bir yapıydı
- Rails World'de (Kanada) tanışılan ikinci Rails geliştiricisinin işe alınmasıyla yapısal değişimler ve olumlu etkiler ortaya çıktı
- Tek hata noktası olan teknik riskin azaltılması
- Yeni bakış açıları ve fikirlerin gelmesi
- Pair programming sayesinde kod kalitesinin iyileşmesi
- Aynı dili konuşan bir geliştiriciyle çalışmanın getirdiği entelektüel canlılık
- Bundan sonra da büyük bir geliştirme ekibi kurma planı yok
- Şimdiye kadar kanıtlandığı gibi, yalnızca Rails tabanlı bir yaklaşımla bile küçük ama güçlü bir ekip anlamlı yazılımlar üretebilir
- Yine de, en verimli solo geliştirici bile iyi bir ekip arkadaşıyla daha da ileri gidebilir gerçeği hissedildi
- PlanGo'nun yolculuğu, Rails'in One-Person Framework yaklaşımının gerçekten işe yaradığını gösteren bir örnek ve
doğru araçlara sahip küçük bir ekibin kendi ölçütlerine göre ciddi bir iş kurabileceğinin kanıtı
- İster ilk ürününü geliştiren solo bir geliştirici olun, ister teknoloji yığınını değerlendiren küçük bir ekip, bu hikâyenin Rails'i en iyi şekilde kullandığınızda nelerin mümkün olabileceğini göstermesi umuluyor
4 yorum
Bu içeriği NotebookLM Audio Overview ile bir podcast'e dönüştürmeyi denedim.
https://notebooklm.google.com/notebook/…
Bu kadarı bile harika görünüyor. Biraz daha cilalamam gerekecek.
Vay... inanılmaz gerçekten. Bu kadar doğal olması...
Vay, bilgi gerçekten çok net anlaşılıyor...
Hacker News görüşleri
Django benzeri deneyime sahip bir kullanıcı kendi uygulamasını işletiyor
Framework’ten daha önemli olanın insan olduğunu savunan bir kullanıcı var
Rails ve Phoenix kullanma deneyimini paylaşan bir kullanıcı var
Rails 7+’ın solo geliştiricilerin de iddialı uygulamalar geliştirmesine yardımcı olduğunu anlatan bir sunum yapan bir kullanıcı var
Yeni bir ortağın Rails geliştiricileri eklemek istediği bir deneyimini paylaşan bir kullanıcı var
AdonisJS ile uygulama geliştiren bir kullanıcı var
Rails’in Django’dan daha iyi olduğu birçok nokta olduğunu düşünen bir kullanıcı var
Rails kullanarak uygulama geliştiren bir solo geliştirici var
Tam yeniden yazımdan kaçınılması gerektiğini savunan bir kullanıcı var
Framework’ün o kadar da önemli olmadığını düşünen bir kullanıcı var