İlk SaaS'iniz İçin Teknoloji Yığını Seçmek: Kurucular İçin Dürüst Bir Rehber

On mühendise ilk SaaS'iniz için hangi teknoloji yığınını kullanmanız gerektiğini sorun, üçü dinî bir kesinlikle verilmiş on beş yanıt alırsınız. Bu yanıtların çoğu doğrudur — onu veren kişi için. Hiçbiri sizinle, nakit ömrünüzle ya da henüz imzalamadığınız müşterilerle ilgili değildir. Bu karara bakarken biraz midesi bulanan bir kurucuysanız, kimsenin yüksek sesle söylemediği şey şu: yığın, inanmanız sağlanandan çok daha az önemlidir ve önemli olduğu birkaç yol da insanların internette tartıştığı yollar değildir.

Bir slayt sunumundan gerçek insanların para ödediği bir ürüne geçen, ilk kez kurucu olan epeyce kişiye yardım ettim. Neredeyse hiçbiri teknik değildi. Neredeyse hepsi, korkutucu miktarda yığın folkloru özümsemiş halde geldi — mikroservislere ihtiyaçları olduğunu, bir çerçevenin "öldüğünü", yanlış seçimin onları mahvedeceğini. Ve neredeyse her seferinde yığın, o yıl verdikleri en önemsiz kararlardan biri oldu. Projeleri öldüren şey kapsam, belirsiz sahiplik ve yanlış şeyi güzelce inşa etmekti. Asla çerçeve değildi.

İşte bu yüzden bu, o kuruculara tek bir kod satırı yazmadan önce verdiğim rehber. Belirli bir yığını kullanmanızı söylemeyecek, çünkü işinizi bilmeden bunu vaat eden herkes size bir şey satıyordur. Bunun yerine size bir düşünme yolu verecek — böylece ne seçerseniz seçin ya da ekibiniz ne önerirse önersin, gergince başınızı sallamak yerine bunu yetişkin gibi mantık süzgecinden geçirebilirsiniz.

Bu karar neden olduğundan daha zor görünüyor

Yığın sorusu devasa görünür çünkü verdiğiniz, geri alınamaz gibi duran ilk seçimdir ve konuşmadığınız bir dile sarılıdır. Postgres, React, Kubernetes, serverless gibi kelimeler, aralarında seçim yapmak bir binanın temelini seçmek gibiymiş gibi ortaya atılır — yanlış yapın, her şey çöker.

Ama yazılım bir bina değildir. Çok daha çok, hâlâ yemek pişirirken yeniden donatabileceğiniz bir mutfağa benzer. Başarılı şirketler yığınlarının parçalarını sürekli yeniden yazar; bir ürünün ilk yüz müşterisini bulan versiyonu, neredeyse hiçbir zaman ilk yüz binine hizmet eden versiyon değildir. İlk yığınınızın amacı sonsuza dek dayanmak değildir. Amaç, bunu birinin isteyip istemediğini öğrenecek kadar hızlı inşa etmenize, değiştirmenize ve piyasaya çıkarmanıza izin vermektir. Bu, "önümüzdeki on yıl için mükemmel"den tamamen farklı — ve çok daha düşük — bir çıtadır.

Bunu kabul ettiğinizde, baskı yarıya düşer. Artık geleceği tahmin etmeye çalışmıyorsunuz. Sizi çalışan bir ürüne ve ödeme yapan kullanıcılara götüren, makul ve geri alınabilir bir bahis yapmaya çalışıyorsunuz. Ve makul bahisler, teknik olmayan bir kurucunun kesinlikle değerlendirebileceği bir şeydir.

Sade bir dille "yığın" aslında nedir

Herhangi bir karar vermeden önce, kelimenin gizemini çözmek faydalı olur. Teknoloji yığını, yazılımınızı inşa etmek ve çalıştırmak için kullanılan araçların toplamından başka bir şey değildir. Onu dört katman olarak düşünebilirsiniz ve hiçbirini derinlemesine anlamanıza gerek yoktur — yalnızca var olduklarını bilmeniz yeterli.

• Ön yüz (frontend) — kullanıcıların tarayıcısında veya uygulamasında gördüğü ve tıkladığı şey. Herkesin sizi yargıladığı kısım budur.
• Arka uç (backend) — bir sunucuda çalışan mantık ve kurallar: kim neyi yapabilir, bunu yaptıklarında ne olur, para nasıl hareket eder.
• Veritabanı — bilgilerinizin gerçekten yaşadığı yer: kullanıcılar, siparişler, abonelikler, kaybetmenize yıkacak her şey.
• Altyapı — yukarıdakilerin hepsini çevrimiçi, yedeklenmiş ve sabaha karşı 3'te erişilebilir tutan sunucular ve hizmetler.

Biri "modern bir JavaScript yığını kullanacağız" ya da "Postgres üzerinde Rails" dediğinde, bu dört katman boyunca seçimleri tarif ediyordur. Hepsi bu kadar. İki kişilik bir yan projeden halka açık bir şirkete kadar her SaaS, bu dört şeyin üst üste yığılmış bir versiyonudur. Görkemli görünen mimari diyagramlar yalnızca bunun, daha fazla kutuyla çizilmiş halidir.

Gerçekten önemli olan şeyler (ve olmayanlar)

İşte çoğu yığın tavsiyesinin yanlış gittiği yer: ilk iki yılınızı etkilemeyen şeyler için optimize eder ve etkileyenleri görmezden gelir. Her iki liste hakkında da açık konuşayım.

Gerçekten önemli olan

Onu kimin inşa edip sürdürebileceği. Tek başına en büyük etken teknoloji değil — insanlardır. Sizin için en iyi yığın, ekibinizin (ya da işe aldığınız ortağın) bugün, akıcı bir şekilde gerçekten çalışabileceği yığındır. Yalnızca tek bir nadir uzmanın anladığı "mükemmel" bir yığın, herhangi bir yetkin geliştiricinin öğrenebileceği sıkıcı bir yığından daha kötü bir seçimdir. İşe alım ve süreklilik, teorik zarafeti her seferinde yener.

Bir şeyleri ne kadar hızlı değiştirebileceğiniz. Erken dönemde ürününüz hakkında sürekli yanılacaksınız. Yığının gerçek görevi, fikrinizi değiştirmeyi ucuz hale getirmektir. Olgun, iyi belgelenmiş, büyük topluluklara sahip araçlar hızlı hareket etmenizi sağlar çünkü sorunlarınızın yanıtları zaten vardır. En yeni araçlar ise hataları keşfeden kişinin siz olmanıza yol açar.

Onun için işe alıp alamayacağınız. Belirsiz bir şey seçin, geleceğinizi onu inşa eden kişiye bağlamış olursunuz. Yaygın ve sıkıcı bir şey seçin, her zaman bir sonraki geliştiriciyi, bir sonraki ajansı, devralacak bir sonraki kişiyi bulabilirsiniz. İşiniz ona bağlı olduğunda sıkıcılık bir özelliktir.

İnsanların söylediğinden çok daha az önemli olan

Ham performans ve "ölçek". Sizin bir ölçek sorununuz yok. Sizin bir henüz-kimse-kullanmıyor sorununuz var, ki bu tam tersi sorundur. Milyonlarca kullanıcı için tasarlanmış mimariler, on bir kullanıcınız olduğunda sizi yavaşlatır. Taklit ettiğiniz ünlü şirketler önce basit versiyonu inşa etti ve sonra, başarıyla finanse ederek yeniden inşa etti. Siz de öyle yapmalısınız.

Bu yıl hangi belirli çerçevenin "kazandığı". Çerçeveler, faturalandırma SaaS'inizi iyi inşa edip etmeyecekleriyle neredeyse hiç ilgisi olmayan bir moda döngüsünde yükselir ve düşer. Ana akım, yaygın olarak kullanılan seçeneklerden herhangi biri işi görür. Trend gürültüdür; sıkıcı, popüler ortadan seçin ve yolunuza devam edin.

"Sıkıcı" teknoloji neden genellikle kazanır

Deneyimli inşacılar arasında, yeni gelenlerin hayal kırıklığına uğratıcı bulduğu sessiz bir bilgelik vardır: yeni bir iş için en iyi teknoloji genellikle sıkıcı, kanıtlanmış, biraz modası geçmiş olandır. Yeni araçlar kötü olduğu için değil, çünkü yaptığınız her seçim sınırlı bir yenilik bütçesi harcar — küçük ekibinizin aynı anda baş edebileceği tanıdık olmayan, desteklenmeyen, şaşırtıcı şeylerin sayısı.

O bütçeyi işinizi özel kılan şeye harcayın — asıl ürüne, yalnızca sizin sahip olduğunuz içgörüye. Onu, sadece modern hissetmek için kimsenin duymadığı bir veritabanına harcamayın. Sıkıcı, olgun bir yığın, sorunların daha önce çözülmüş olması, belgelerin var olması, işe alımın kolay olması ve tek bakımcısı ilgisini kaybettiğinde aracın gelecek yıl yok olmaması demektir. Sıkıcılık, tüm heyecanınızı karşılığını verdiği yere koymanızı sağlar: müşteriye.

Yapay zekânın da tabloyu biraz değiştirdiği yer burası — ve abartının ima ettiği şekilde değil. Yapay zekâ kodlama asistanları, sıkıcı, popüler teknolojilerde çarpıcı biçimde daha iyidir, çünkü onlar hakkında on yıllık genel yanıtlar üzerinde eğitildiler. Ana akım bir yığın seçin, ekibiniz (ve araçlarınız) bedavaya daha hızlı yardım alır. Egzotik bir şey seçin ve tam da en az karşılayabileceğiniz anda yapayalnız kalırsınız.

Gerçekten kullanabileceğiniz bir karar yöntemi

İlkeler yeter. İşte ister kendiniz seçiyor, ister bir serbest çalışana brief veriyor, ister bir ajansın önerdiğini değerlendiriyor olun, bir karara varmanın somut bir yolu. Bunların hiçbiri kod yazmanızı gerektirmiyor — yalnızca doğru şeyleri sormanızı ve yanıtları tartmanızı.

1. 1
   Teknolojiden değil, ekipten başlayın

   Şunu sorun: bunu önümüzdeki iki yıl boyunca kim inşa edip sürdürecek? Zaten iyi bildikleri her ne ise, güçlü varsayılanınız odur. Bir trend için yığın değiştirmek, akıcılığı nadiren yener.
2. 2
   Varsayılan olarak ana akım ve kanıtlanmış olanı alın

   Her katmanın popüler, iyi belgelenmiş ortasından seçin. Bir araç için hızlıca eğitimler, işler ve büyük topluluklar bulamıyorsanız, bunu bir özellik değil bir uyarı olarak değerlendirin.
3. 3
   Ölçek için değil, değişim için optimize edin

   Ürününüzü düzenlemeyi ucuz ve hızlı kılan seçeneği tercih edin. Ürün hakkında defalarca yanılacaksınız — yığının görevi, yanılmayı atlatılabilir kılmaktır.
4. 4
   Mimariyi olabildiğince basit tutun

   Bir veritabanı. Bir arka uç. Bir ön yüz. Gerçek, ölçülmüş bir sorun sizi zorlayana kadar mikroservis yok, akıllı dağıtık hiçbir şey yok. Basitlik bir taviz değil, hedeftir.
5. 5
   Neden seçtiğinizi yazın

   Bir paragraf: kim inşa ediyor, neyi seçtiniz ve yeniden değerlendirmeniz için neyin değişmesi gerekir. Bu not, biri ateşli bir görüş okuduğunda kararı yeniden tartışmaktan sizi kurtarır.

Başka hiçbir şeyi izlemeseniz de, bir ve dört numaralı adımları izleyin. Sahip olduğunuz insanlarla, işe yarayan en basit mimari üzerinde inşa edin. Bu kombinasyon, çoğu ilk SaaS ürününü batıran iki başarısızlık biçimini sessizce önler: onu sürdürebilecek kimsenin olmaması ve kendi boyutu için fazla karmaşık bir sistem.

Bir yığın öneren herkese soracağınız sorular

Çoğu kurucu yığını tek başına seçmez — bir geliştirici, bir ajans ya da CTO bir arkadaş bir tane önerir. Teknolojiyi kendiniz doğrulamanıza gerek yok. Bir avuç soru sormanız ve nasıl yanıtladıklarını dinlemeniz yeterli. Kendinden emin, sade dilli yanıtlar iyi bir işarettir. Savunmacı jargon değildir.

• "Neden bu ve sıkıcı popüler seçenek değil?" — iyi bir yanıt, trend olanla değil, sizin özel ihtiyaçlarınızla ilgilidir.
• "Sizi bir otobüs çarpsa, bunu başka biri ne kadar kolay devralabilir?" — yanıt, seçimin ne kadar nadir ve riskli olduğunu ortaya koyar.
• "Bu mimarinin hâlâ işe yarayan en basit versiyonu nedir?" — basitliğe mi yoksa karmaşıklığa mı uzandıklarına dikkat edin.
• "Bunun için bir sonraki geliştiriciyi işe almak ne kadar kolay olacak?" — yaygın beceriler sağlıklı bir pazar, egzotik beceriler bağımlılık demektir.
• "Üç ay içinde temel bir özelliği değiştirmemiz gerektiğinde ne olur?" — değişimin korkulan değil, ucuz olduğunu duymak istersiniz.

İyi fikir gibi görünen yaygın tuzaklar

Bazı kalıplar o kadar sık ortaya çıkar ki adlandırmaya değer, çünkü her biri o an sorumluca hisseder ve sonradan size pahalıya patlar.

Sahip olmadığınız bir ölçek için inşa etmek. "Doğru yapma" dürtüsü, kurucuları daha on kullanıcıları yokken milyonlarca kullanıcı için mimari kurmaya iter. Bu geleceğe hazırlığın her bir parçası, asla gelmeyebilecek bir sorunu çözmek için şimdi, zaman ve parayla ödediğiniz bir karmaşıklıktır. Bir sonraki yüz kullanıcı için inşa edin. Büyüme gerekli kıldığında yeniden mimari kurun — ve bunun mutlu bir sorun olmasına izin verin.

En yeni şeyin peşinden koşmak. Geçen ay çıkan parlak bir çerçevenin geçmişi yoktur, belgeleri incedir ve topluluğu küçüktür. Gecelerinizi ürününüzü inşa etmek yerine aracın hatalarını ayıklayarak geçirirsiniz. Bırakın erken benimseyenler başkaları olsun; sizin çıkaracak bir işiniz var.

En ucuz olana, tercih ettikleri her ne ise onunla iş vermek. En düşük teklif çoğu zaman yalnızca o tek ekibin bildiği belirsiz bir yığınla gelir. Yollarınızı ayırdığınız gün, ürününüz başka kimsenin ulaşamadığı bir adaya dönüşür. Başta ucuz, sonra yıkıcı. Dışarıdan iş verirken bile ana akım, işe alınabilir teknolojide ısrar edin — özellikle dışarıdan iş verirken.

Yığınınızı yeniden gözden geçirmenin gerçekten zamanı geldiğinde

Bunların hiçbiri "asla değiştirme" anlamına gelmiyor. Gerçek nedenlerle, ölçülmüş, hayal edilmemiş nedenlerle değiştir anlamına geliyor. Bir blog yazısı sizi kaygılandırdığında değil, somut sinyaller belirdiğinde yığınınızı geliştirmenin gerçekten zamanının geldiğini bileceksiniz.

Kalıba dikkat edin: gerçek nedenler, asıl işinizdeki ölçülmüş acıyla ilgilidir. Sahte nedenler moda, kıyaslama ve huzursuzlukla ilgilidir. Gerçek bir sinyal belirdiğinde, her şeyi altı ay durduran kahramanca bir yeniden yazımla tüm yığını değil — bir seferde bir parçayı değiştirirsiniz. Devrim değil, evrim.

Sık sorulan sorular