En hüzünlü “Just Ship It” hikâyesi (2020)

 (kitze.io)
1 puan yazan GN⁺ 2024-07-05 | 1 yorum | WhatsApp'ta paylaş
  • 2018'de başlayan yan proje için MVP birkaç gün içinde hazırdı, ancak yayınlama tarihi sürekli ertelenince 2 yıl boyunca yayınlanmamış bir projeye dönüştü
  • Gecikmenin merkezinde tekrarlanan “sadece bir şey daha” kararı vardı; React Native ve Expo bile öğrenilerek ürünün kapsamı büyüdü
  • Aynı problemi çözen rakip uygulama yavaş ve hatalıydı, ama çoktan yayınlanmış, kullanıcı ve topluluk kazanmış, her hafta iyileştiriliyordu
  • 30 günlük deneme süresinin ardından rakip uygulamaya ödeme yapılınca, yalnızca hard diskte duran kendi uygulaması fiilen ölü bir ürün hâline geldi
  • 2024 güncellemesinde, 2022'de üretkenlik uygulaması Benji'nin sonunda yayınlandığı belirtiliyor; sonuç, klişe olsa da önce piyasaya çıkarma tarafına daha yakın

Birkaç günde yapılan MVP'nin 2 yıl boyunca neden yayınlanamadığı

  • Uygulamanın geliştirilmesine 1 Ocak 2018'de başlandı ve MVP birkaç gün içinde hazırdı
  • 0.0.1 alfa sürümü de yayınlanabilecek durumdaydı, ancak her seferinde “sadece bir özellik daha”, “sadece bir ekran daha” denilerek çıkış ertelendi
  • “Düzgün bir yerel mobil uygulama yoksa insanlar kullanmaz” diye düşünülerek React Native öğrenmeye ve birkaç ay daha harcamaya karar verildi
  • Sonraki 2 yıl boyunca web platformu, React Native, Expo, GraphQL, teknoloji yığını üzerine düşünme, başka projelere geçiş, Sizzy gibi başka uygulamalar yayınlama, tutkuyu kaybedip yeniden kazanma döngüsü tekrarlandı
  • Sonunda geliştirme durduruldu ve o uygulamayı yayınlama fikrinden de vazgeçildi

Aynı problemi çözen bir uygulamanın keşfedildiği an

  • Zaman geçtikçe kendi uygulamasını kullanmaya devam ederken pek çok özelliğe ihtiyaç olduğunu fark etti ve yeniden geliştirmesi ya da bir alternatif bulması gereken bir duruma geldi
  • Alternatif uygulamanın açılış sayfasını görünce, çözmeye çalıştığı problemi birinin çoktan çözdüğü duygusu güçlü biçimde üzerine geldi
  • Daha önce kendi uygulamasının videosunu birkaç kişiye göndermiş olduğundan, videonun paylaşılmış olabileceğinden şüphelenecek kadar özelliklerin ve problem anlayışının benzer olduğunu hissetti
  • Ancak rakip uygulamanın varlığının onların suçu olmadığını, kendisinin çok yavaş kaldığı ve zamanında yayınlamadığı için böyle olduğunu kabul etti

Kusursuzluktan önce yayınlamayı seçen rakip uygulama

  • Hesap oluşturup yardım merkezi videolarını izlerken, uygulama biçimini akıllıca bulduğu her anda kendisinin bir rakip olduğunu hatırladı
  • 2 yıl boyunca kendi uygulamasının acemice, hatalı ve özellik bakımından eksik olduğu için kimsenin kullanmayacağını düşünmüştü; ancak rakip uygulamayı deneyince bu yargısının yanlış olduğunu gördü
  • Rakip uygulama da yıllarca geliştirilmişti, ama hâlâ yavaş, hatalı ve pek de cilalanmamış durumdaydı
  • Mobil uygulama, senkronizasyonun 10 saniye süreceği kadar iyi değildi; ancak zaten yayınlanmış bir üründü ve kullanıcılar bir sonraki güncellemeyi bekleyebilirdi
  • Yapılacaklar listesi büyük olsa da her hafta yayın yapmayı sürdürerek uygulama ve topluluk birlikte büyüyordu

Ödeme sonrası kalan ders

  • 30 günlük deneme süresi bittikten sonra kredi kartı bilgilerini girdi ve sadece bir abone değil, bir hayran oldu
  • Ödeme bildirimi, kendi ürününü yayınlayamamış olduğu gerçeğini tekrar tekrar hatırlatan bir deneyim olarak kaldı
  • Bu anda kendi uygulamasının resmen öldüğünü kabul etti
  • Aynı durumda olan insanların çoğu projeye başlayalı henüz yalnızca birkaç hafta olmuş olabilir; bu yüzden aynı hatadan kaçınmak gerekir
  • “Sadece bir şey daha” dediğiniz şey kimlik doğrulama, ödeme ya da boilerplate'i yeniden yapmaksa bu bir tuzaktır; daha sonra bu tuzağı azaltmak için Zero To Shipped oluşturuldu

2024 güncellemesi: Benji sonunda yayınlandı

  • 2024 güncellemesine göre Benji sonunda 2022'de yayınlandı
  • Yayınlanma nedeni, hiçbir rakip uygulamanın kendi vizyonuna yeterince yakın olmamasıydı
  • İstediği uygulama; Todos, Habits, Planner, Goals, Pomodoros, Meal tracking, Fasting, Hydration, Packing, Trips gibi şeyleri birleştiren bir yapıdaydı
  • Benji'de insanların kendi yaşamlarını iyileştirirken başarılarını ve kazanımlarını paylaştığı herkese açık bir zaman çizelgesi de var
  • Klişe gibi gelse de derin bir nefes alın ve yine de Just Ship It yapın

İlgili okumalar

1 yorum

 
GN⁺ 2024-07-05
Hacker News görüşleri

  • Bu tür “o zamanlar sadece çıkarılmadığı için sona eren hikâyeler”de önemli bir ipucu vardır: Bazen üzerinde çalışılan uygulamanın değeri, aceleye getirilemeyecek teknik detaylarda yatar ve böyle durumlarda “sadece çıkar gitsin” doğru cevap değildir
    Yazılım mühendisi/mimarın işi, yönetimin “hemen gönderin” baskısına mümkün olduğunca direnmek de olabilir. Doğrudan sahibi olduğunuz bir ürün değilse ve yayına almak size doğrudan fayda sağlamıyorsa, daha fazla zaman harcayıp daha profesyonel bir sonuç çıkarabiliyorsanız o zamanı harcamalısınız. JIRA bileti alıp olabildiğince hızlı özensiz kod kusan bir otomatik makine değilsiniz; böyle çalışmaya devam ederseniz zihinsel olarak yıpranır ve sonunda burnout yaşarsınız
    Şirkette hisseniz yoksa şirket kârını maksimize etmek sizin işiniz değil; özgeçmişinize utanmadan koyabileceğiniz iyi yazılım üretmek sizin işinizdir. Yine rastgele bir son tarihi tutturmanın verdiği rahatlama, kısa vadeli olumsuz bir motivasyondur ve uzun sürmez; bu yüzden yukarıdan gelen baskıya direnip işi doğru yapmak gerekir. Kovulsanız bile bugünlerde zaten iş değiştirerek yükselmek daha olasıdır

    • “Şirkette hissen yoksa kârlılığı umursamana gerek yok” demek, bir yazılım geliştiricide kıdem eksikliğini gösteren kötü bir tavır gibi geliyor. Kâr amacı gütmeyen bir kurum değilse, şirketin tüm üyeleri kârlılığa katkı sağlamalıdır
      Ancak kârlılık, “hemen çıkar gitsin” ile aynı anlama gelmez. Bunları sık sık karıştıran bir şirket varsa, bu yönetim tarafında kıdem eksikliğinin işaretidir
      Geliştiricinin işi iyi yazılım değil, iyi ürün yapmaya daha yakındır. İyi ürün için çoğu zaman iyi yazılım gerekir, ama her zaman değil; arkasında berbat yazılım olan harika ürünler de çoktur. Ürün, satış ve geliştirme arasındaki gerilim; kısa, orta ve uzun vadeli değeri en üst düzeye çıkaran uzlaşılara dönüşmelidir ve geliştirici, nelerin kabaca geçilebileceğini, şirketin önceliklerinin ne olduğunu ve ne zaman taviz vermeyip iyi yazılım üretmesi gerektiğini anlamalıdır
      Yazılım kalitesinde asla taviz veremeyen bir geliştirici, gerçekten taviz verilmemesi gereken anlarda da etkisini kaybeder
    • Önce neden geliştirdiğine bakmak gerekir. Hobi, keyif ya da kodun güzelliği için olabilir ama çoğu zaman amaç, birinin ihtiyaç duyduğu işi yazılıma yaptırmaktır
      Bu yüzden 1. öncelik, kullanıcı için değer üretmek ve mümkün olduğunca verimli geliştirmektir. Kimsenin kullanmadığı yazılımın ne anlamı var
      Geliştiricinin işi iyi yazılım yapmak değil, kullanıcıya değer ulaştırmaktır. Kariyerimde gördüğüm örneklerde daha çok geliştiricilerin aşırı tasarıma kapıldığını, kimsenin ihtiyaç duymadığı özelliklerle kodu şişirdiğini ve belki hiç gelmeyecek gelecekteki geliştirmelere hazırlanmak için kodu büyüttüğünü gördüm. Bu yüzden asıl zor olan minimal kalmaktır; metin de sanki bunu anlatıyor
    • Bu yorumun tamamı, iş arkadaşlarıyla ilişkiyi tamamen düşmanca gören ve neredeyse hiç güven duymayan birinin yazısı gibi okunuyor. Epey yorucu olmalı
    • Erken dönem startup çalışanlarından biriydim; taviz vermeseydik şirketin bugün var olmama ihtimali yüksekti. Böyle bir yaklaşım, ekip etkisinin sonuca sınırlı olduğu büyük ve köklü şirketlerde ancak işe yarar
      Küçük ve orta ölçekli şirketlerde kesinlikle taviz gerekir ve en iyi iş sonucuna götüren seçimi yapmak da profesyonelliğin parçasıdır
      Birçok geliştirici, birden fazla yönetici katmanı, PM ve tasarımcı tarafından “korunduğu” için iş tarafıyla bağlantısı zayıf kalıyor. Ürünü hızlı çıkarırsanız geri bildirimi de hızlı alırsınız ve uygulamanın varsayımlarla örtüşüp örtüşmediğini değerlendirme şansı doğar. Baskı altında “mükemmel” çözümü dağıtıp sonra baştan yazmaktan daha az stresliydi
      Şu anki işimde geliştirici olarak yaptığım şey, karmaşıklığı azaltmak ve PM ile tasarımcıların ilk planı asgari düzeye indirmesini sağlamak. Böylece keyfi son tarihler daha az stresli oluyor ve gecikmenin etkisi de küçülüyor
    • Bu bana hiciv gibi geliyor. “Senin işin değilse yanlış olanı yap, senin işinse hızlı çıkar”, “işin özgeçmişine koyup kendini iyi hissetmek” gibi etkileyici cümleler arka arkaya geliyor
      Değerli olan kısmı, belirli bir işe fazla saplanmamak ve kovulma konusunda aşırı endişelenmemek olabilir; ama bunun gerekçesinin açıklaması da bence yanlış. Böyle düşmanca bir tavırdaki insanlarla gerçekten birlikte çalışıyor olabileceğimiz şaşırtıcı
      Bazı insanlar oyun teorisinde yanlış kadranda yaşamayı seviyor gibi görünüyor

  • “Uygulama videomu bu insanlarla kimin paylaştığından şüphelendim. Çünkü kelimenin tam anlamıyla aynı sorunu çözüyorduk” kısmını okuyunca, geçmişte iyi sayılabilecek bir uygulama fikri olan biriyle karşılaşmam aklıma geldi
    Uygulamayı ücretsiz kodlamamı istedi ve geliri paylaşmayı önerdi. Ben de kendisinin ne katkı sağlayacağını sordum; şirketi “yöneteceğini” ve %50 payı “fikri kendisinin bulduğu” için istediğini söyledi. Ben de ona 6 aylık bir önden gitme süresi vereceğimi, o zamana kadar ürünü pazara çıkaramazsa kendim yapacağımı söyledim

    • Bir zamanlar bağımsız bir oyun projesine katılmıştım. Fikir sıradandı, hatta berbat bir oyuna yakın bir şeydi ama üçümüz de o alanda yazılım geliştirme deneyimi istiyorduk
      Üç kişiden ikisi oturup bir şeyleri şekillendirmeye başlamıştı; üçüncü kişi ise bozuk kodu SVN'e yükledi, tüm fikri kendi hanesine yazdığı bir tasarım belgesi hazırladı, sonra da toplantı çağırıp kendisinin oyun tasarımcısı olduğunu ve bizim başka yerde oyun yaparsak dava açacağını söyledi. Gerçekte katkı veren iki kişi birbirine baktı ve projeyi bıraktı. Elindeki tüm kartları açmıştı ve ne kadar vasat biri olduğu ortaya çıkmıştı
      Sonradan Steam'de benzer fikirde bir oyun gördüm. Bağımsız olarak düşünmüşlerse ne âlâ; o ezikten çalmış olsalar da olurdu ve onun altında sonuna kadar dayanmışlarsa parayı hak etmişlerdir
    • Mantık ve programlama tarafına aşırı yatkın biri olarak, aslında böyle biriyle tanışmak isterdim. Ben kendimi fikir insanı olarak görmüyorum
      Fikir gerçekten iyiyse ve kişi güven veriyorsa, dürüst olmak gerekirse bu hiç de fena bir teklif olmayabilirdi
    • Satış, pazarlama, muhasebe ve şirketi yürütmek için gereken diğer her şeyi üstlenmek %50, hatta belki daha da fazla değer eder. Ama kodlayacak kişinin yeterince yetkin olma ihtimali yüksekken, onun şirketi “yönetecek” kadar yetkin olma ihtimali düşük görünüyor
    • Karşınızdaki kişinin ruh hâlini hiç bilmiyorsanız, bunu söylemenin ne kadar akıllıca olduğundan emin değilim
      Birine “6 ay sonra o harika fikrini çalacağım” demenin uygun olduğunu düşünüyorsanız, umarım o kişi sorun çıkarabilecek ya da daha uç durumda zarar verebilecek bir tip değildir

  • Birinin benim problemimi benim yerime çözmesini isterim. Şu anda bu probleme sarılmamın tek nedeni, gidip satın alabileceğim bir çözümün olmaması
    Birinin kan ter içinde benim problemimi çözüp üstüne on-call ve bakım yükünü de üstlenmesi sevindirici bir şey olurdu
    Bu problemi neden mutlaka kişinin kendisi çözmek zorunda? Kendi çözümü neden mutlaka bir iş olmak zorunda? İş, kendin ve müşterilerin için değer üretmektir. Eğer problemin kendisine takıntılıysan, başka birinin büyük emek verip onu çözmesine minnet duyabilirsin; müşteriye takıntılıysan da geri bildirim almak için çoktan müşteriye bir şey sunmuş olmalıydın

    • Bazı tek kişilik geliştiriciler, yeni bir fikri hayata geçirip onu belli ölçüde başarılı bir işe dönüştürdükten, pazarı sıkıca kavradıktan sonra daha büyük bir şirkete satıp büyük para kazanmak istiyor gibi görünüyor
      Uzun vadede şirket işletmek isteyen insan çok olmayabilir ama ilginç bir problemi çözdüğü ya da onunla uğraştığı için bir anda büyük para almayı da çoğu insan reddetmez
    • Orijinal yazının yazarıyım: Benim için bunun önemli olmasının nedeni, bir süredir kullandığım uygulamanın durağanlaşması ve artık güncelleme almamasıydı. Verimlilik hakkında daha çok şey öğrendikçe o uygulamanın sınırlarına ulaştım ve daha fazla özellik istedim
      Kendi uygulamama koymak istediğim fikirler aklıma gelmeye devam etti ama başka geliştiriciler muhtemelen bu fikirleri uygulamakla ilgilenmeyecekti. Kontrol istiyordum ve sonunda bu yüzden Benji’yi yayınladım: https://benji.so

  • Orijinal yazının yazarıyım. Bu yazıyı güncellemem gerekiyor. Yıllar sonra, bu yazı her gündeme geldiğinde altına gelen HN yorumları gerçekten bana motivasyon verdi
    İnsanlar sürekli “neden uygulamayı artık yayınlamıyorsun?” diyordu, ben de sonunda yayınladım
    Sonuna kadar götürdüğüm için mutluyum ve bu kategorideki tüm rakiplerden çok daha iyi olduğunu düşünüyorum
    https://benji.so adresinde görülebilir. Landing page üzerinde hâlâ çalışıyorum

    • Landing page tarayıcıyı kasıyor. Birkaç görsel içeren bir açılış ekranı için bunun nasıl mümkün olduğunu anlamıyorum. O sayfada tam olarak ne yapıyorsun?
    • Ben de benzer şekilde bir türlü yayınlanamayan bir uygulama geliştirme döngüsünden geçtim. React ile başlayıp React Native ve Flutter’a geçtim, sonunda GraphQL’den SQLite’a da taşındım
      Benim uygulamamın da alışkanlık motivasyonu, hedef takibini, iş planlamayı ve yeniden planlamayı birleştiren benzer hedefleri vardı. Yıllarca üzerinde çalıştım ve bir gün bunu bootstrap bir şirkete dönüştürme fikri kimliğime fazlasıyla bağlanmıştı
      Projeyi bırakma kararı birkaç aşamada geldi ama büyük kapanış anlarından biri, uzun vadede uygulama geliştiricisi olarak yaşamak istemediğimi fark etmemdi. Bırakmak zordu ama şimdi bu karardan memnunum. Orijinal yazıdaki gibi ileride yeniden canlanabilir diye “hiçbir şey tamamen kaybolmaz” da denebilir ama bu özel projeye geri döneceğimi sanmıyorum
      Çoğu verimlilik uygulamasındaki “yüksek bilişsel yük” sorununu aşmak için temel fikirlerden biri yaşam modülleri pazaryeri idi. Örneğin bir fitness influencer’ı antrenman rutinlerini, beslenme planlarını ve günlük şablonlarını paketleyip satabilir, kullanıcı da bunu kendi hayatına “kurabilir”
      Büyük dil modelleri, kopuşu tespit edip nedenini tahmin etmeyi ya da “yapılmayan davranışlara” yanıt vermeyi çok daha mümkün hâle getirecek. Bunu, her gün düzenli olarak verimlilik uygulaması kullanan tip A kişiliklerden olmayan insanlar için önemli buluyorum
    • Az önce denedim, algılanan saat dilimi adı “Africa/Ceuta (Romance Standard Time) (UTC+01:00) Brussels, Copenhagen, Madrid, Paris” olarak görünüyor
      GMT farkı doğru ama Brussels, Copenhagen, Madrid, Paris Afrika’da değil, o yüzden aşırı kafa karıştırıcı. Kullandığınız saat dilimi bilgisini kontrol etmeniz iyi olabilir
      Aşağıdaki yorumlara bakınca bunun aslında bir sorun olmadığı anlaşılıyor
    • Beyaz arka plan üzerindeki beyaz menü bağlantıları görünmüyor. Haber vermek için bırakıyorum: https://i.imgur.com/Yd1hniV.png
    • Güzel görünüyor. Belki denerim. İsmini şu arkadaştan mı aldın: https://en.wikipedia.org/wiki/Benji? 6-8 yaşlarımdayken ona bayılırdım
      Bir de “rakibin” adını söylememen karşısında hayal kırıklığı ve şüphe ifade ettiğim için kusura bakma. Artık kendi uygulamanı yayınladığına göre, o rakip hâlâ ortada olsa bile adını söyleme ihtimalin herhâlde daha da düşmüştür

  • Kendi sisteminin gerçek kullanıcısı olunca bakış açın tamamen değişiyor. Benim de kendim için yaptığım bir şey vardı ve hazır olmadığını, hiç kullanılamaz olduğunu düşünüyordum
    Projeyi bıraktıktan sonra onu gerçek bir kullanıcı gibi kullanmaya karar verince, kullanıcıların sayısız küçük soruna alıştığını ve otomatik olarak etrafından dolaşmanın yollarını bulduğunu fark ettim. Bir şeyi yapan kişi, çok sayıdaki pürüzün diskalifiye edici olmadığını ve kullanıcıların birçok eksiği büyük çaba harcamadan aşabildiğini sık sık unutuyor. O noktada mükemmeliyetçilik daha çok gurur meselesine dönüşüyor
    Onu yapan kişi olduğunu bir süreliğine görmezden gelip, bir süre düzeltme yapmayı da yasaklayarak gerçekten kullanmak her şeyi değiştirebilir

    • Bu yüzden “yayınla ve hızlı yinele” yaklaşımının çoğu zaman en iyi yol olduğunu düşünüyorum. Her yazılım projesinde ölümcül hatalar olabilir. Bir muhasebe paketi muhasebeyi düzgün yapamıyorsa elbette öylece yayınlanmamalı; ama bir rapor bir nedenle iki kez gösteriliyorsa, kullanıcılar bir sonraki iterasyona kadar bunu tolere edebilir. Yeter ki o sonraki iterasyon aylar ya da yıllar sonra gelmesin
      Gerçekte, gerçek kullanıcılara açılmadan önce onların karşılaşacağı “hataların” çoğunu bulamazsın. Yayınlamazsan, kullanıcıyı gerçekten etkileyen hataları düzeltme şansın da olmaz
    • Az önce kullandığım uygulamada düzgün çalışmayan yerleşik bir iOS web tarayıcısı vardı
      Ben de sayfayı doğrudan webde açıp kullandım; kullanıcı adı ve şifre zaten doğal olarak iCloud ile senkronizeydi. Safari’de kullanıcı akışına yeniden girmem 5 saniye, işi bitirmem de 30 saniye sürdü

  • Bu, “just ship it”in en iyi örneği değil. Üretkenlik uygulamaları, yapılacaklar, alışkanlık takibi, harcama takibi, günlük tutma, egzersiz planı gibi kategorilerde pek çok kişi aynı fikri birbirinden bağımsız olarak düşünüyor
    Harcamaları kaydetmeyi sağlayan bir uygulama fikrini bulduğumda kendimi ne kadar zeki hissettiğimi anlatamam. Sonra Play Store’a baktım. KRAZAM da bunu 5 yıl önceki “The Hustle” videosunda tiye almıştı

    • Bu, muhtemelen aşırı fazla üretilmiş uygulama kategorileri tarihinde en fazla üretilmiş kategori
      Bu, yeni bir varyasyonun başarılı olamayacağı anlamına gelmiyor. Sonuçta başarılı olanların çoğu tamamen özgün değildi. Sadece biri önce kendi sürümünü çıkarıp kazanır mı diye endişeleniyorsanız, etrafa bir bakmanız yeterli
    • “Play Store’a baktım” kısmı yazının ana fikrini kaçırmış gibi. Mesele, rakipler olsa bile ürünü yayımlamak. Hatta rakipler, kötü bir işaret değil, fikri doğrulayan iyi bir işarettir

  • Kişisel olarak “komik olmaya fazla kasan” yazı stiline dayanamıyorum

    • Katılıyorum. Okuması oldukça yorucu. Zamanında yapılmış bir iki alaycılık tamam ama fazlası olmamalı
    • Bu konuda yalnız değilsiniz; insanların farklı zevkleri olması gayet normal

  • Okurken yarıda bıraktım. Fazla çocuksu ve aşırı cringe
    Sonuçta sadece bir proof of concept yapıp onunla yetinmişler. Üzücü ama hayat böyle. Onlar işi yaptı ve karşılığını aldı
    Buradan çıkarılacak ders şu: Fikirler sahip olunabilecek şeyler değildir

  • Buna tamamen katılıyorum. Kviklet’e başladığımızda 3 kişiydik ve içimizden biri diğer ikisinden çok daha mükemmeliyetçiydi. Açıkçası berbat olan ilk web sitesi sürümünü yayına almak bile çok ikna gerektirdi, depoyu herkese açmak ise daha da zordu
    O “kurucu ortak” erken dönemde ayrıldı ama erken yayımlayıp satmayı denemiş olmamız gerçekten iyi oldu
    İşler yolunda gitmedi ve bir alıcı da bulamadık ama birinin para ödeyip ödemeyeceğini hiç bilmeden, karanlıkta sadece umutla tutunup hâlâ ürün geliştiriyor olduğumuzu hayal etmek korkunç
    Şimdi yedek plan olarak açık kaynak yaptık ve birkaç hayli iyi kullanıcımız da oldu. Küçük bir topluluk denebilir sanırım: https://github.com/kviklet/kviklet
    Bu, 1 yıl önce umduğum startup başarı hikâyesi değil ama hâlâ sadece beklenti içinde, gerçeklik duygusundan yoksun şekilde takılıp kalmaktan çok daha iyi. Açık kaynak olması, destek ya da premium sürüm satarak biraz para kazanılamayacağı anlamına da gelmiyor, değil mi. Şu an sadece eğlenceli bir yan proje

    • “Veritabanı sorguları için Pull Request benzeri inceleme/onay akışı” açıklaması pek iyi değil. Sorguların onay gerektirdiği izlenimini vermemeli
      mutation, edit, update, modification gibi kelimeler kullanılmalı. query teknik olarak doğru olsa bile çağrışım olarak yanlış ve kafa karıştırıcı geliyor

  • Kendim için bir şey yapıyorsam, bir başkası daha önce yaptı diye üzülmem. Bu sadece fikrin iyi olduğunun kanıtıdır
    Elbette kafamda ve kâğıt üstünde duran birçok kişisel proje, hatta gerçekten biraz başladıklarım bile satış için yayımlanmak üzere düşünülmüş değil. Bunlar benim istediğim ya da arkadaşlarımın, ailemin veya başka insanların faydalı bulabileceği şeyler
    Alfa kalite düzeyindeyse bile yayımlayıp birinin “Fikir faydalı ama uygulama zayıfmış, ben bunu daha iyi yapayım” diye düşünmesini isteyebilirim

    • Gerçekçi olmak gerekirse, neredeyse her durumda birileri zaten sizden önce davranmıştır. Tarihte ilk kez bir şeyi otomatikleştiriyor olsanız bile, mevcut manuel yöntem ilk rakibinizdir. Yazıdaki uygulama da yalnızca diğer uygulamalarla değil, hedef kitlenin zaten kullandığı her türlü parçalı çözüm kombinasyonuyla rekabet ediyor
      Üstelik ilk giren siz olsanız bile kısa sürede rakipler çıkıp avantajınızı aşındıracaktır ve önde kalmak için sürekli çaba gerekir
      O yüzden nasıl olsa her zaman sizden önce biri vardır ve rekabet şimdi ya da sonra kesin olduğuna göre, başkasının önce davranmasını dert etmek yerine rekabet avantajına odaklanmak gerekir. Görünüşe göre asıl yazar da sonunda bu farkındalığa varmış; umarım işleri iyi gider