Eşik Düştü: ProductLog’un Bana Gösterdiği Build in Public Riski

ProductLog’u, kurucuların yaptıkları işi ilerledikçe kaydedebilmeleri için geliştirdim. Platform yayında ve benim için hâlâ anlamlı bir çalışma alanı. Fakat temel vaadi aynı zamanda bir gerilim yaratıyor: Düzenli tutulan kamusal bir kayıt, bir ürünün hikâyesini dağınık blog yazılarına kıyasla daha kolay takip edilir ve anlaşılır kılar. Yapay zekâ bu kayıtları daha hızlı bir araya getirip işleyebildiğinde, aynı açıklık rakipler için de işe yarar bir kestirmeye dönüşebilir.

Arvid Kahl, Nisan 2026’da build in public yaklaşımını yeniden ele aldı. Geçmişte pratik bir eşik gördüğünü yazıyordu: Şirketler aylık tekrarlayan gelirleri yaklaşık 20–30 bin dolara geldiğinde, ne yaptıklarını daha az ayrıntıyla paylaşmaya başlıyordu. Ona göre yapay zekâ ajanlarıyla yazılım geliştirme bu hesabı değiştirdi. Eski eşik, kendi ifadesiyle, “etkili biçimde sıfıra indi.”

Bu, Kahl’ın risk değerlendirmesi; yazılım rekabeti için ölçülmüş bir yasa değil. Yine de ciddiye alınması gereken bir tarafı var. Kararlı bir rakip, açık kaynaklardan malzeme toplayabilir, ürünü inceleyebilir ve AI ile kabaca benzer bir ürün çıkarmak için gereken süreyi kısaltabilir. Kahl, tek bir promptun kusursuz bir kopya üreteceğini söylemiyor. Daha inandırıcı bir ilk sürüme giden yolun kısaldığını söylüyor.

ProductLog paradoksu

Build in public yapmanın zaten bir ödünleşimi vardı. Geri bildirim, güven ve ilk kullanıcıları kazanacak kadar paylaşmak; rakibin önüne uygulama kılavuzu koyacak kadar ayrıntıya girmemek.

ProductLog ilk kısmı kolaylaştırıyor. Bir kurucu kararları, değişiklikleri, denemeleri ve bunların nedenlerini okunabilir bir sıra içinde tutabiliyor. Bu, başka kurucular için değerli olabilir. Benim kendi düşünme biçimimi yeniden kurmayı da kolaylaştırabilir.

Kendi ProductLog kayıtlarımda bunu gördüm. Bazı notlar müşteri varsayımını, pazara yaklaşımı, geleceğe dair yönü ve uygulamadan çıkan dersi bir araya getiriyor. Tek bir kayıt tam bir spesifikasyon değil. Fakat bu notlar biriktikçe, neyi inşa etmeye çalıştığımı ve nerede zayıf kalabileceğimi anlamanın maliyeti düşebiliyor.

Asıl mesele burada. Her açık not anında bir klona dönüşmüyor. Ancak yeterince kesin not, bir rakibin normalde kendisinin yapması gereken keşif işinin önemli kısmını ortadan kaldırabiliyor.

İmitasyon hızlandı, ama her şey eşitlenmedi

AI, dışarıdan görünen özelliklerin ve temel ürün akışlarının benzerini üretmeyi kolaylaştırdı. Gerçek bir işi kurmanın ve işletmenin maliyetini sıfırlamadı.

Kod yazmak işin bir bölümü. Ürünün dikkat kazanması, müşteriyi anlaması, istisnalarla başa çıkması, belirsizlik altında karar vermesi ve ilk demodan sonra çalışmaya devam etmesi gerekiyor. Dağıtım gücü, müşteri ilişkileri, birikmiş alan bilgisi ve sistemi işletme becerisi kamusal bir sayfadan daha zor yeniden üretiliyor.

Zor olması imkânsız olduğu anlamına gelmiyor. Bunların hiçbiri kalıcı bir kale değil. Sadece oluşmaları zaman, muhakeme ve tekrar eden emek isteyen varlıklar. Bu ayrım önemli. Çünkü hem “kodun artık hiçbir değeri yok” sonucunu hem de “kodu saklamak işi korur” rahatlığını sorgulamayı gerektiriyor.

ProductLog için soru bu nedenle paylaşmayı bırakıp bırakmamak değil. Belirli bir ayrıntının insanlara gerçek bir dersi anlamalarında mı yardımcı olduğu, yoksa henüz sınanmamış bir planı kopyalamayı mı kolaylaştırdığı.

Dersi paylaşın, aktif tarifi koruyun

Build in public içindeki en değerli malzeme çoğu zaman muhakemedir: Bir kararın neden verildiği, hangi kısıtın o kararı değiştirdiği, neyin işlemediği ve sonrasında ne öğrenildiği. Bunlar başka bir kurucuya düşünmek için malzeme verir. Buna karşılık, bir ürünün güncel varsayımlarını, sıradaki önceliklerini ve operasyonel ayrıntılarını eksiksiz yayımlamak başka bir şeydir.

Artık bazı ayrıntılara farklı yaklaşıyorum. Bir yanlış yoldan, ne öğrettiğini anlayabildiğimde yazabilirim. Ürünün çözmeye çalıştığı problemi anlatabilirim. Ancak sınamadığım bir stratejinin bütün karar dizisini yayımlamak zorunda değilim.

Bu, ProductLog’dan geri çekilmek değil. Kamusal malzemenin daha kolay toplanıp özetlendiği ve yeniden kullanıldığı bir dönemde sorumlu şeffaflığın sınırını daha iyi çizmek.

Pratik çerçeveyi AI Çağında Build in Public: Neyi Paylaşmalı, Neyi Saklamalı? yazısında ele aldım. Oradaki soru tek tek içerikler için geçerli: ekran görüntüsü, metrik, teknik not ya da plan. Bu yazının konusu ise o çerçevenin arkasındaki kişisel çelişki. Kurucuların işini görünür kılacağı bir yer kurdum; sonra kendi işimin ne kadarını orada görünür kılacağımı yeniden düşünmek zorunda kaldım.

Cevap susmak değil. Kamusal kaydı, işi öğrenmek isteyenler için yararlı kılarken işin kendisini yapmanın yerine geçen bir kestirmeye dönüştürmemek.