3 Yıl Sonra Başarısız Olan Startup’ımın Kodunu Açtım

• Konfig, API entegrasyonlarını kolaylaştıran bir geliştirici araçları startup’ı olarak başladı; 3 yıl sonra kapanırken ürün kodunu ve operasyonel çıktıları içeren codebase’ini yayımladı
• Ana ürün, OpenAPI spesifikasyonlarından istemci kütüphaneleri oluşturan SDK Generator idi; daha sonra dokümantasyon ve etkileşimli API test ortamına kadar genişledi
• Bazı startup müşterilerinden ilgi gördü, ancak sözleşme zorluğu ve düşük fiyat seviyesi nedeniyle bunu çok hızlı büyüyen bir iş haline getirmek zordu
• Sonrasında dikey B2B SaaS yapay zeka ürününe pivot etti, ancak çok sayıda görüşme ve satış sürecine rağmen büyük bir iş olduğuna ikna edecek pazar tepkisini (traction) bulamadı
• Açık depo, kapanış anındaki haliyle duruyor; ürün kodu, pivot denemeleri, satış script’leri, dağıtım ayarları ve pazarlama web sitesini hiçbir temizlik ya da düzeltme yapılmadan içeriyor

---

Konfig’in geliştirdiği API geliştirici araçları

• Konfig, 2022 sonunda başlayan bir API geliştirici araçları startup’ıydı; geliştiricilerin API’lerle çalışma biçimini basitleştirmeye odaklandı
• Amaç, SDK üretimi, dokümantasyon ve test çevresindeki araçları iyileştirmekti
• Ana ürünü SDK Generator idi
  • Girdi olarak OpenAPI spesifikasyonlarını alıp çeşitli programlama dilleri için istemci kütüphaneleri üretiyordu
  • Daha sonra API dokümantasyon aracı ve etkileşimli API test ortamına genişledi

Büyüme sınırları ve yapay zeka pivotu

• Bazı startup müşterilerinde traction vardı, ancak bu çok hızlı büyüyen bir işe dönüşmedi
• Potansiyel müşterilerle sözleşme imzalamak zordu; kanıtlanabilir ROI olsa bile fiyat seviyesi çok düşüktü
• Üretken yapay zekadaki gelişmelerin ardından, daha önce çözülmesi zor olan sorunları çözebileceğini düşünerek dikey B2B SaaS yapay zeka ürününe pivot etti
• Çeşitli fikirler için kullanıcı görüşmeleri ve satış çalışmaları yürüttü, ancak devasa bir işe dönüşecek yön olduğuna güven verecek kadar traction bulamadı

Kapanış anındaki haliyle açılan depo

• Açık depo konfig-dev/konfig
• Depo, şirketin kapandığı andaki haliyle yayımlandı
  • Temizlik yok
  • Cilalama yok
  • Düzeltme yok
  • Codebase, filtrelenmemiş gerçek bir startup kodu halini gösteriyor

3 yıl boyunca yapılan başlıca ürünler

• SDK Generator: OpenAPI tabanlı SDK üreticisi
• Markdown and OpenAPI Documentation: Markdown ve OpenAPI tabanlı dokümantasyon
• API Demos (Markdown Based Jupyter Notebooks): Markdown tabanlı Jupyter Notebook biçiminde API demoları
• SDKs for Public APIs: Açık API’ler için SDK koleksiyonu

Birlikte açılan operasyon kodu ve deneyler

• Satış ve pazarlamayla ilgili kodlar da dahil
  • Shell script for generating cold outbound message: Cold outbound mesajı üretmek için shell script’i
  • Programmatic SEO Scripting: Programatik SEO script’i
  • Marketing website: Pazarlama web sitesi
• Müşteri ve satışla ilgili çıktılar da yer alıyor
  • References to live customer deployments and pre-sales artifacts: Canlı müşteri dağıtımlarına ve ön satış çıktılarının referanslarına göndermeler
  • Custom Notion Database Integration: Özel Notion veritabanı entegrasyonu
• Ürün operasyonu ve geliştirme araçları da görülebiliyor
  • Product Documentation: Ürün dokümantasyonu
  • Modified Changeset Bot: Özel monorepo yapılandırmasını destekleyen değiştirilmiş Changeset Bot
  • SDK Generator Integration Tests using Earthly: Earthly kullanan SDK Generator entegrasyon testleri
  • Python Code Formatting Service: Python kod formatlama servisi
  • render.com deployment configuration: render.yaml dağıtım ayarı
• Yapay zeka pivotu ve diğer denemeler de depoda yer alıyor
  • AI Pivot Experimentation: Yapay zeka pivot denemeleri
  • API Documentation Generator Tool using LLMs/HTMX/Django: LLM, HTMX ve Django kullanan API dokümantasyonu üretme aracı
  • Python script for cropping blog post images: Blog görsellerini kırpmak için Python script’i

Kurucunun bıraktığı değerlendirme

• Dylan Huang, Mart 2022’de işinden ayrılarak startup’a odaklandı ve başarısızlık ihtimalini bilmesine rağmen denedi
• Bu başarısızlığı, kendisine başarıdan daha fazlasını öğreten bir deneyim olarak görüyor
• Bir sonraki adımda yeni fırsatları keşfetmeyi, işe alım piyasasında kendisine uygun bir pozisyon aramayı, öğrenmeye ve gelişmeye devam etmeyi planlıyor
• Bir gün yeniden doğrudan bir şeyler inşa etme mücadelesine girişme ihtimalini de açık bırakıyor

[GN⁺]

Hacker News yorumları

• “Hiper büyüyen” “dev bir iş” yerine küçük bir işi hedefleseydi, şimdiye kadar geride ne kadar çok harika niş ürün kalmış olurdu diye düşünüyorum

  • Bunu söylemek kolay ama iş pratiğe gelince gerçekten zor; çünkü 3-5 yıl boyunca fiilen maaş almadan dayanıp, yatırım almış bir işle benzer sonuçlar beklemeniz gerekiyor
    Gelişmiş ülkelerde 2-3 kişilik bir startup’ın hayatta kalması için aylık 10 dolarlık lisanslardan inanılmaz sayıda satması gerekir; fırsat maliyetini de hesaba katmak lazım
  • Her ay gereken giderleri karşılamak için yatırım alıyorsanız, yatırımcı açısından portföy hesabının tutması için hiper büyüme potansiyeli olması gerekir
    En baştan küçük ve sürdürülebilir bir işi hedefleyip başarılı olursanız yatırımdan kaçınabilirsiniz; ama şirketin orta/son aşamalarında tamamen yeni bir yöne pivot ettiyseniz, muhtemelen nakit rezervlerinin çoğunu yakmışsınızdır
  • Böyle bir sonuçta, büyük bir şirkette işe girip benzer getiriyi risksiz almak daha mantıklı olur
  • Ben de bu kısmı merak etmiştim. Yaşam maliyetinin düşük olduğu bir bölgede danışmanlık yapan, bootstrapped bir şirketin üç kurucu ortağından biriyim; birkaç yıldır kuruculara yılda 50 bin dolar maaş ödüyoruz ve ne özellikle şanslıydık ne de iş kararlarımız olağanüstü iyiydi, ama oldukça iyi gidiyoruz
    Bu yıl gelir 400 bin dolar, kâr 150 bin dolar, büyüme oranı %40 oldu ve satış görünümü yıl başına kıyasla çok daha iyi. Gelecek yıl da güçlü büyüme bekliyoruz; pazar doygunluğundan çok uzağız, bu yüzden önümüzdeki birkaç yıl daha büyüme alanı büyük
    Maaşla kârın 1/3’ünü toplarsak bu yıl için 100 bin dolar ediyor; %40 büyümeyle şirket her 2 yılda ikiye katlanır. İşler iyi giderse yalnızca maaş ve kâr bile oldukça iyi hale gelir; buna bir de kurucuların birkaç milyon dolar kazanabileceği bir satış fırsatı eklenir
  • Burada “Gördün mü, zor demiştim!” gibi bir alt anlam hissediliyor
    Google gibi bir şirket kurmaya çalışmak da Basecamp gibi bir şirket kurmaya çalışmak da gayet geçerli; sadece farklı türde şirketler
    Asıl “düşük riskli iş” kurmanın riskini küçümsemek kolay; her iş zordur. Konfig’i alkışlıyorum

• Bir Konfig müşterisi olarak gerçekten üzücü. Muhtemelen ilk müşterilerinden biriydik; sanırım erken commit’lerde de adımız geçiyordu
  Dylan ve Anh-Tuan bizim için gerçek birkaç sorunu çok iyi çözdü. Üretilen SDK’ları ve güzel görünen barındırılmış dokümantasyon/eğitimleri tek yerde sunuyordu; API’mizi çağırarak kullanıcıların doğrudan gerçek verilerle deneme yapmasını sağlıyordu
  Konfig’den önce API’yi saran SDK’ları el yordamıyla ve dağınık şekilde yazıyorduk; dokümantasyonu ReadMe üzerinde barındırıyorduk ama API’mizin istek imzalama gereksinimleri yüzünden interaktif olarak düzgün çalışmıyordu
  Konfig’in açık kaynak olarak yayımlaması sayesinde artık dokümantasyonu kendimiz barındırıyoruz: https://docs.snaptrade.com/
  Bu ekibe gerçekten saygı duyuyorum ve bir şekilde devam etmenin yolunu bulabilmiş olmalarını isterdim
  Konfig gibi müşterilerin sevdiği ama geliri gereken kadar büyümeyen bir ürün işletiyorsanız, fiyatı daha da artırmayı düşünmek de mantıklı olabilir. Biz Konfig’in talep ettiği tutarın 2-3 katını da öderdik ve büyüdükçe daha fazlasını da öderdik; ama onlar istemedi, SDK başına aylık ücret ya da demo başına aylık ücret gibi kullanıma dayalı bir fiyatlandırma da oluşturmadılar

  • Konfig’i sizin ürününüz sayesinde öğrendim. Dokümantasyon o kadar iyiydi ki arkasında ne kullandığınıza bakmak zorunda kaldım; Swagger veya Redoc’tan gerçekten daha iyi
  • https://github.com/OpenAPITools/openapi-generator’ı doğrudan denememiş olmanızı merak ettim
  • Hafif bir API dokümantasyonu alternatifi istiyorsanız Scalar’ı öneririm. Basit ve kullanımı kolay, ama Swagger dokümantasyonundan çok daha iyi

• Amerikan startup kültürü gerçekten tuhaf. Her şeyin aşırı hızlı ölçeklenmesi gerekmiyor; her şeyin devasa olması da gerekmiyor
  İşler sürdürülebilirliğe daha çok odaklanmalı; 2-3 yıl içinde üç kez pivot edip sonra kapıya kilit vurmak şeklinde olmamalı

  • Bir açıdan doğru, ama başka bir açıdan da “hiper ölçeklenme yoksa başarısızlık” şeklindeki bu takıntılı odak, Amerikan startup ekosistemini bugünkü konumuna taşıyan ve dünyanın geri kalanından çok daha önde olmasının nedeni olan şey de olabilir
    Avrupa’daki birçok startup kurucusuna “5 yıl sonra 15-20 çalışan civarında plato yapmış, istikrarlı nakit akışı olan ve kendine yılda 200-250 bin dolar ödeyen” bir şirket derseniz bunu büyük bir başarı sayar. ABD’de ise, özellikle risk sermayesi aldıysanız, bu başarısızlık olarak görülebilir
    Silikon Vadisi’nde bir risk sermayedarının açıkça “şirketi 50 milyon dolara satmayı başarı sayıyorsan zihniyetin yanlış ve seninle çalışmak istemem” dediğini duymuştum
    Büyük meydan okumaları ve büyük riskleri almadan küçük başarılara ve istikrarlı büyümeye razı olursanız büyük ödülleri asla alamazsınız. Birey için daha sağlıklı olabilir ama ekonominin bütünü için kötü olabilir
  • Kârlı küçük işletmelerin, yani küçük ekipleri ve uzun vadeli hedefleri olan, sıkıcı görünebilecek şirketlerin HN’in ön sayfasına pek çıkmadığını düşünüyorum; çünkü gerçek dışı büyüklükte hedefler koymuyorlar
    Bu kültürün “hızlı hareket et ve bir şeyleri kır” tarzı düşünceyi benimsemesi ilginç; sanki çoğunlukla teknoloji sektörüne uygulanıyor. Birkaç kez başarısız olmuş iş insanına “seri girişimci” denmesi de öyle; sürdürülemez bir şirketi satmayı başarı olarak görmek zor
    Birkaç sporda başarısız olmuş birinin kendine “seri sporcu” demesi nasıl olurdu diye düşününce komik geliyor
  • Sorun, risk sermayesi aldığınız anda hiper ölçeklenme tarafına itilmeniz
    Risk sermayesi almazsanız, danışmanlık gibi bir yolla kendinizi finanse edemiyorsanız kendi kendine yaşayabilir hale gelmenin yolu çok daha zor ve uzun. Buradaki model 37 Signals, ama onlar Rails’i yapan şirket olduğu için çok istisnai bir örnek
    Üstelik o noktaya ulaşsanız bile risk sermayesi almış bir rakip, daha iyi bağlantılar ve parayla gelip sizi ezebilir
  • Avrupa’dayım ve tam olarak aynı zorlukları yaşayan bir şirkette çalışıyorum
    Büyük şirketlere yönelik B2B satış döngüleri akıl almaz derecede uzun, KOBİ’lere satabileceğiniz fiyat seviyeleri ise yeterli değil
    Değer sağlasak ve müşterilerin zamanından tasarruf ettirsek bile, o değeri anlatmak her zaman zor
    Davulun sesi uzaktan hoş gelir ama B2B işi yaparken yıllarca ışıkları açık tutmak için aynı çileleri tekrarlamak, her ay benzer konuşmaları farklı müşterilerle yapmak ve yılda 10 kez neden değerli olduğunu aynı şekilde açıklamak zorundaysanız insanların buna sıkışıp kalmak istememesini anlıyorum. Tükenmişlik de hızlı gelebilir
    Bu yüzden değeri apaçık olan ve insanların “paramı alın” diye bağırdığı bir iş fikri bulmak istemelerini de anlıyorum
  • Batılı şirketlerin yatay değil dikey ölçeklenmeyi tercih etmesinin birkaç nedeni var
    İlki yatırım getirisi. Başkalarının parasını çekmek istiyorsanız, onlar doğal olarak getiri bekler; akıllı yatırımcı portföyünü çeşitlendirdiği için birçok yatırımın başarısız olacağını bilir. Bu yüzden kayıpları telafi etmek adına tüm yatırımlarının mümkün olduğunca büyümesi için baskı yapar ve az sayıdaki aşırı başarılı şirketin başarısızlıkları kapatmasını bekler
    Bu dikey büyüme sadece startuplarda değil büyük şirketlerde de görülüyor. Bunda biçimcilik, aşırı düzenleme ve bürokrasinin büyük rol oynadığını düşünüyorum. İzinler, vergiler ve bordro hesaplarının kurulması gibi sayısız süreçten geçmeniz gerekiyorsa, halka açılmak için daha da fazla prosedür varsa, yeni bir şirketi ayırıp kurmak yerine yerleşik bir şirketin faaliyet kapsamını genişletmek çok daha ucuz ve daha düşük riskli olabilir

• Sanırım rakiptik. ReadMe.com’un kurucusuyum; biz API dokümantasyonu ve SDK’lar vb. sunuyoruz
  Bizim tam olarak neden başarılı olduğumuzu bilmiyorum, ama ben de sayısız yanlış başlangıç yaşadım ve insanların gözle görülür biçimde heyecanlandığı noktaya ulaşana kadar temel fikri azar azar yineleyerek geliştirdim
  Bu pazarın zor olduğunu bildiğim için mühendislik dışındaki işlere de çok zaman ve emek harcadım; özellikle daha açık ve dürüst göründüğümüzde Hacker News bize her zaman olumlu yaklaştı
  Daha fazlasını duymak için kendisiyle özel olarak iletişime geçmeyi düşünüyorum
  Genel olarak, ortaya koyduğu tüm emek için tebrik ederim. Şirket kurmak ve kendine inanmak inanılmaz zor bir iş; bununla gurur duymalı

  • ReadMe’nin Konfig’den daha başarılı olmasının nedeni 8 yıl daha önce başlamış olması olabilir. Konfig iyi bir fikirdi ve iyi de uygulandı, ama belki de sadece zamanlaması doğru değildi
  • Hazır buradayken söyleyeyim, ReadMe giriş ekranındaki CSS geçiş efekti hatırladığım en güçlü markalaşma öğelerinden biri olarak kaldı. Kim düşündüyse gerçekten harika iş çıkarmış

• Yakın gelecekte bu sonucu çok göreceğiz gibi. Yapay zeka balonu sönerken benzer şeyler tekrarlanacak gibi duruyor

  • Bunu şöyle yazmış olsaydı o emeğe daha çok saygı duyardım
    “Üretken yapay zekayı dikey B2B SaaS ürünlerinde kullanarak daha önce çözülemeyen sorunları çözebileceğimizi düşündük ve denedik. Birçok fikir geliştirdik ve sunduk, ancak kullanıcı tepkileri devasa bir iş kurmak için doğru yönde olduğumuza bizi ikna edecek kadar olumlu değildi.”
    Orijinal hâliyle ilk izlenim şu oluyor: “Bu yazıyı yazan kişi geçici ve dar bir moda kültürüne derinden gömülmüş; içgüdüsel olarak itici geliyor ve tamamen başarısız olduktan hemen sonra bile psikolojik olarak oradan çıkamamış.”
  • Kodu açık kaynak yapıp vazgeçmek, nihai yapay zeka pivodu. Çünkü yeni modeller yaptığınız işi öğrenip bir gün daha iyisini yapacak

• Ürünün tam oturmadığı, pivot yönü ararken yapay zekayı cevap olarak seçip başarısız olduğu hikâyesi ilk kez yaşanmıyor
  Daha önce de söyledim ama tekrarlamaya değer. Yapay zekanın neyi iyi neyi kötü yaptığını anladığımızda, yapay zekayı hedef değil araç olarak ele almaya başlayacağız ve ürün fikri üretme süreci de istikrara kavuşacak

  • Bunu zaten biliyoruz. Yapay zeka inandırıcı görünen şeyler uydurmakta iyi; gerçeklere ya da doğrulamaya dayanabilecek çıktılar üretmekte zayıf
  • Ürünün kendisi fena değildi. OpenAPI tanımlarından SDK üreten o ürüne seve seve para ödemiş ve çok değer elde etmiş bir startupta çalışmıştım
    Bu yüzden burada sorunun ürün-pazar uyumu olmadığını düşünüyorum
  • Yani yapay zekanın bir şeyleri otomatikleştirmesi kötü bir ürün fikrini kurtaramaz mı demek istiyorsun? Kimsenin istemediği bir işi daha verimli yapmak iş değildir gibi
  • API kavramı ortadan kalkmalı; yapay zekalar sadece doğal dille birbirleriyle konuşmalı

• Bunu nasıl değerlendirmem gerektiğinden pek emin değilim. Bir yandan öz değerlendirme yapmasını, rahatsız edici gerçeklerle yüzleşmesini ve epey geniş bir araç seti oluşturmasını takdir ediyorum.
  Ama içine bakınca, araçları saran araçlardan ibaret. API sınıflandırma aracı, ağır işin önemli bir kısmını OpenAI’ye devrediyor gibi görünüyor.
  “Siz dünya standartlarında bir sınıflandırıcısınız. Bu API’leri şu gruplardan birine yerleştirin.”
  Dosyaların geri kalanı ise bağlantı kodu ve model-view-controller sınırlarının biraz bulanıklaşmış hâli. Testler de gördüm; dış kontrolün dışında çok değişikliğe açık araçları sarmalarken bunun önemli olacağını düşündüm. Ama pratikte, IntelliJ’in varsayılan olarak verdiği contextLoads() fonksiyonel testi gibi, bağımlılıkların bulunduğunu ve derlemenin başarısız olmadığını kontrol etme düzeyindeydi.
  Bir vizyon var ve Pareto ilkesine de uyuyor; ama pazarın kendi şeylerini bakımda tutmakla ilgilenmediği varsayımını doğrulamaya çalışırken, içeride kendi bakım sorunlarını da çözememişler gibi hissettiriyor.
  Eğer bunun nedenini önce kendileri için çözebilselerdi, başkaları için de çözebilirlerdi; fakat bunun için gerçekten kullanılan bir ürünün olması, acıyı hissetmek ve son kullanıcıyla empati kurabilmek gerekiyor gibi görünen bir ikilem var.

• Başarısız bir startup utanılacak bir şey değil. Çoğumuz denemeye cesaret bile edemiyoruz.
  Koda büyük ilgi beklemek zor. İş ve insanlar ortadan kalktıktan sonra bir şirketin kodunun değeri, özel bir teknik gizli silah yoksa epey olumsuz.
  Teknik olarak etkileyici bir parça olsa bile insanlar muhtemelen sadece o parçanın nasıl çalıştığını anlamaya çalışır; kodun kendisini kullanmaz.

  • Konfig’in kurucusuyum. %100 katılıyorum. Kimseye Konfig’i doğrudan çözümleyip dağıtmayı önermem.
    Yine de bir müşteri, Konfig’in kapanmasının etkileriyle başa çıkmanın bir yolunu ararken dokümantasyon platformumuzu kendi ortamında dağıtmayı başardı.
  • Giderek daha az başarısız olan birkaç startup deneyiminden zor yoldan öğrendiğim şey şu:
    Hızlıca gelir üretecek bir iş planınız ya da çok büyük yatırımınız yoksa bir teknoloji startup’ı kurmamalısınız. Genelde işin nereye gideceğine dair asgari bir sezginiz bile yoksa yatırım almak da zordur; teknik insanlar da çoğu zaman iş tarafını yeterince anlamaz.
    Şirketlerin çoğu startup değil, sadece şirkettir. Geliri olan ve faturalarını ödeyen şirketlerdir. Startup ise geliri olmadan ödünç zaman ve parayla yaşayan şirkettir; özellikle de o para kendi paranızsa bir plana ihtiyacınız vardır.
    Girişim sermayesi alan şirketlerin çoğu başarısız olur. Girişim sermayesinin işi, başarısız olacak şirketlerin hızlı başarısız olmasını sağlamaktır; kendi işlerini ise başarısız olmayıp patlayıcı biçimde büyüyen az sayıdaki şirketle ayakta tutarlar. “Hızlandırma” ya da “yatırım alma”, başarı yolunda olduğunuz anlamına gelmez; olasılıkları yenmeniz gereken bir konuma çıktığınız ve fazla zamanınız kalmadığı anlamına gelir.
    Geliri olan başarılı bir şirketseniz girişim sermayesine ihtiyacınız yoktur. O hâlde onlarla neden konuştuğunuzu sormalısınız. Gelir yaratmak zorsa, girişim sermayesi bunu sizin yerinize düzeltemez.
    Birçok girişim sermayedarı tembeldir ve ancak başarı zaten geldikten sonra ilgi gösterir. Bu yüzden erken yatırım alan şirketlerin başarısız olduğu, yatırım alamayan şirketlerin ise başarılı olduğu tuhaf bir dinamik oluşur.
    Mevcut şirket 4 yıldır tamamen bootstrapped şekilde çalışıyor. Gelir tarafında zorlanıyoruz, işi mümkün olan zaman aralıklarına sıkıştırıyoruz ve ben çoğunlukla yandan yaptığım danışmanlıkla geçiniyorum. Şirket 3 yıl üst üste en başarılı yılını geçirdi ve yakında danışmanlığı bırakıp işe odaklanabilecek noktaya yaklaşmış durumdayım; ama uzun bir yolculuk oldu.
    Açık kaynak konusunda, işe özel kod veya temel fikrî mülkiyet olmayan şeyleri yayımlıyoruz. Bir sonraki şirketi kurduğumda aynı angaryaları yeniden yapmak istememem de bunun önemli bir nedeni. Bu tür şeylerin hızı nasıl düşürdüğünü deneyimledim.
    Startup’larda fikrî mülkiyete takıntılı çok insan var; ama gerçekçi olmak gerekirse çoğu yazılım o kadar değerli değil. Yine de onu üretmek zaman, para ve enerji gerektiriyor.
    Bu yüzden başlıca kullanıcısı ben olacağım birçok araç ve framework’ü yayımlıyorum. Sonraki projelerde de kullanmaya devam etmek için.

• Kod dökümünün kendisi ilginç olabilir, ama lisansı yok gibi görünüyor. Düzgün bir açık kaynak lisansı eklenirse çok daha faydalı olur.

  • Yorumdan yaklaşık bir saat sonra MIT LICENSE dosyası eklenmiş.

• Geliştirici araçları pazarı gerçekten zor.
  Neredeyse her mimari karar “Bu sorunu çözmek için hangi açık kaynak aracı kullanabilirim?” sorusuna dönüşüyor.
  Kimse para ödemek istemiyor; bunda sorun yok.

  • Öyle ama geliştiricilerin çoğu, kendi yaşadıkları sorunların dışındaki sorunları pek fark etmiyor; o sorunlar da genelde geliştirici aracı sorunları oluyor.
    Bu yüzden başka alanlarda muazzam ihtiyaç olmasına rağmen geliştirici aracı startup’ı kuran şirket sayısı artıyor.
    Bir şeyler başlatmak isteyen deneyimli geliştiricilerin, sorunlara ve alan uzmanlığına sahip, şirket kurma isteği olan insanları tesadüf ve networking dışında bulabilmesinin bir yolu olsaydı, çok fazla değer açığa çıkabilirdi.
  • Geliştiricilere araç satmak zordur. Sürekli uyum sağlayıp değişen sayısız açık kaynak araçla rekabet etmeniz gerekir; iyi fikirler hızla emilir ve kopyalanır.
    Bu yüzden çoğu ticari aracın fayda açısından ömrü sınırlıdır ve genellikle “olsa iyi olur” düzeyinde kalır.
    Ayrıca birçok geliştirici ücretli çalışandır ve kişisel araç bütçesi yoktur. Pazar fiilen freelance geliştiricilerle geliştirici istihdam eden yöneticilere daralır.
    Takım yöneticileri bu tür harcamaları dikkatle inceler ve genelde bütçeleri de yüksek değildir. Çoğu şirkette geliştiriciler için kişisel araç bütçesi diye bir şey yoktur.
    Freelance çalışanlar da çoğunlukla kendilerine para ödeyen şirketin kullandığı araçları kullanır; bunlar da çoğu zaman ücretsiz araçlardır. Ücretli araçlar, yüklenici lisanslarını da düşünmeyi gerektirdiğinden freelance çalışanlarla çalışmayı daha karmaşık hâle getirir. Bu yüzden işleri basit tutmak için bu tür araçlardan kaçınma eğilimi vardır.
  • Daha da ötesi, geliştirici araçları yanıltıcı derecede zordur. Geliştirici aracı yapmak, bir şirket ya da startup için kazanma formülü gibi görünmeye çok müsaittir. Çünkü siz de geliştiricisinizdir ve geçmişte bizzat yaşadığınız bir sorunu keşfetmiş olma ihtimaliniz yüksektir.
    Geliştiricilerin nerede toplandığını ve neyin işe yaradığını da bilirsiniz; bu yüzden her şey yolunda görünür.
    Ama söylendiği gibi birçok geliştirici para ödemek istemez ve biraz daha az kullanışlı olsa bile gereken işi yapan açık kaynak çözümler bulur. Üstelik karşınızdakiler işi ve hayatı yazılım üretmek olan insanlar olduğundan, cevap “kendim yaparım” da olabilir.
  • Tamamen doğru değil. Sadece 10 dolarlık 50 faturayı işlemekle zaman kaybetmek istemiyorum.
    Birden fazla hizmeti tek bir faturada birleştiren bir iş yok mu? Yoksa hâlâ AWS, Azure, GCloud mu kullanmak zorundayız?