Herkesin önünde üretmek (build in public) nasıl yapılır?

"Build in public", yani ürününü herkesin gözü önünde üretmek, son yıllarda solo kurucular arasında neredeyse bir zorunluluk gibi anlatıldı. X'te gelir ekran görüntüleri, "1. gün / 30. gün" paylaşımları, açık gelir tabloları… Bir yandan da Indie Hackers'ta, Hacker News'te ve Reddit'te giderek artan bir şüphe var: "Bu gerçekten müşteri getiriyor mu, yoksa birbirimizi alkışlıyor muyuz?"

Bu yazıda yöntemi en uzun süre ve en görünür şekilde uygulayanların (Pieter Levels, Arvid Kahl, Tony Dinh, Marc Lou, Cory Zue) anlattıklarını ve topluluktaki eleştirileri yan yana koyduk. Amacımız sana "yap" ya da "yapma" demek değil; neyi, ne zaman, kime paylaşacağına karar verebilmen.

Build in public aslında ne işe yarar?

Pieter Levels, 2017'de Hoodmaps'i ilk satır koddan yayına kadar Twitch'te canlı yayınlayıp Twitter'da günlük ekran görüntüleriyle paylaştığını blogunda anlatır. Kendi saydığı faydalar üç tane: takıldığı her yerde izleyenlerin yardım etmesi, herkesin önünde olduğu için tembellik yapamaması ve sürecin kendisinin pazarlamaya dönüşmesi. Aynı yazıda bedelini de saklamıyor: hataların yüzlerce kişinin önünde olması stresliydi ve ürün çok kullanılsa da para kazandırmadı.

Cory Zue ise yıllarca açık gelir raporları yayınladıktan sonra yazdığı "Farewell, Building in Public" yazısında, yöntemin ona destekleyici bir kitle, fikir veren, ürünlerini alan ve tanıtan insanlar, hatta gerçek arkadaşlar kazandırdığını söyler. Tek başına çalışan biri için kendine hesap verme aracı olduğunu da ekler.

Kısacası build in public; geri bildirim, hesap verebilirlik ve zamanla biriken güven için iyi bir araç. Ama tek başına bir müşteri edinme kanalı değil. Bunu aklında tutarak devam et.

En büyük tuzak: kitlen müşterin değilse

Hacker News'te laike9m'in "No One Builds in Public" yazısı üzerine açılan tartışmanın en çok oy alan yorumu tam bu noktaya dokunuyordu: build in public, kurucuyu diğer indie hacker'lar için araç yapmaya itiyor. Çünkü seni X'te takip edenler çoğunlukla başka kurucular. Aynı başlıkta Canny'nin kurucusu ise yöntemin ilk günlerde paha biçilmez bir pazarlama kanalı olduğunu, ama en iyi kitlen teknoloji insanlarıysa çalıştığını söylüyordu.

r/EntrepreneurRideAlong'da "Build in public, indie hacker'ların kendine söylediği en büyük yalan" başlıklı bir gönderi de benzer bir sonuca vardı: müşteriler ürünleri arama, topluluklar, tavsiye ve reklamla bulur; kurucunun günlük güncellemeleriyle değil. Yorumcuların çoğu, yöntemin girişimcilere yönelik ürünlerde işe yaradığını, diğerlerinde bir güven katmanı olduğunu söyledi.

Senin için soru şu: bir nakliye firmaları için rota planlama aracı yapıyorsan, nakliyeciler X'te build in public hesaplarını takip ediyor mu? Muhtemelen hayır. O zaman paylaşımın amacı müşteri bulmak değil, öğrenmek ve hesap vermek olur. Müşteriyi ise ayrı bir kanaldan aramaya devam etmen gerekir.

Neyi paylaşmalısın?

Arvid Kahl'ın "Building in Public: What to Share at Which Stage of Your Journey" yazısı bu konuda en derli toplu kaynaklardan biri. Her aşamada işe yarayan paylaşımlar için önerdikleri şöyle özetlenebilir:

• Aldığın kararları ve arkasındaki gerekçeleri anlat.
• Planlarını paylaş; sonra onlara uyduğunu görmek güven yaratır.
• Küçük de olsa öğrendiklerini yaz.
• Rakamları ne şişir ne küçült.
• Yarım kalmış eskizler, notlar, ekran görüntüleri gibi görseller kullan.
• Kullandığın araçları ve bunlardaki değişiklikleri anlat.

Hacker News tartışmasında da benzer bir orta yol vardı: bazı yorumcular gelir rakamı paylaşmadan "garaj kapısı açık" çalıştıklarını, ekran görüntüsü ve süreç paylaştıklarını, asıl değerin çıkmaz sokakları ve teknik zorlukları anlatmakta olduğunu söyledi.

Türkiye'den bir örnek düşün: veteriner klinikleri için randevu hatırlatma aracı yapıyorsun. "Bugün 3 yeni kayıt" yerine "Görüştüğüm 6 klinikten 5'i hatırlatmayı SMS yerine WhatsApp'tan istedi, bu yüzden SMS entegrasyonunu erteledim" demek hem daha faydalı hem de seni takip eden bir veteriner için daha anlamlı.

Ürün aşamasına göre ne değişir?

Arvid Kahl paylaşımları aşamalara göre de ayırıyor. Hazırlık döneminde varsayımlarını nasıl doğruladığını ve müşteri geri bildiriminin fikrini nasıl değiştirdiğini; gelir öncesi dönemde müşteri çekmek için denediğin deneyleri, başarısız olanlar dahil; ilk müşteriler geldiğinde fiyatlandırma denemelerini ve özelliklere gelen tepkileri; daha sonra yol haritanı, neyi neden kestiğini paylaşmanı öneriyor. Bir de önemli bir not düşüyor: ilk müşterilerine teşekkür etmek güzel, ama yalnızca onların iznini alarak.

Bunu kendi 30 günlük dönemine uyarlarsan: ilk hafta problem ve görüşme notları, ikinci hafta ilk ekranlar, üçüncü hafta ilk kullanıcı tepkileri, dördüncü hafta fiyat ve lansman kararı. Her hafta bir şey öğrendiğin için her hafta paylaşacak bir şeyin olur.

Neyi paylaşmamalısın?

Kahl'ın en net uyarısı şu: hiçbir şeyi paylaşmak zorunda değilsin. Acı veren ya da işine zarar verebilecek konuları kendine sakla. Paylaşmadan önce sorman gereken soru, bunun hem sana hem de başka birine bir şey öğretip öğretmediği.

Cory Zue'nun bırakma gerekçeleri de neyi saklaman gerektiğine dair iyi bir liste. Gelir arttıkça kutlamalar övünme gibi durmaya başlamış, açık rakamlar kopyacıları çekmiş ve en önemli içgörülerini paylaşmak rakiplere hazır bir yol haritası vermiş. Tony Dinh de Product Hunt röportajında aynı ikilemi anlatıyor: gelir paylaşmak insanların ürünü kanıtlanmış görmesini sağlıyor ama kopyacıları da çekiyor. r/EntrepreneurRideAlong'daki tartışmada bir yorumcu ayrıca fikri mülkiyet ve patent riskine dikkat çekmişti.

Pratik bir kural: müşteri listesi, tam olarak hangi kanaldan ne kadar kazandığın ve rakibin kopyalayabileceği "gizli tarif" senin. Süreç, kararlar ve dersler paylaşılabilir.

Ne sıklıkla ve nerede?

Kaynakların hiçbiri sihirli bir sıklık vermiyor; ama uygulayanlardan bir ders çıkıyor: düzen, hacimden önemli. Tony Dinh 2021'de X'e katıldığında build in public'e başladığını, tweet'ler, röportajlar ve podcast'ler üzerinden mümkün olduğunca çok şey paylaştığını, bir projesinin viral olmasıyla iki günden kısa sürede binlerce takipçi kazandığını anlatıyor. Ama bu bir patlama; arkasında aylarca süren düzenli paylaşım var.

Marc Lou'nun kendi sitesi ise yöntemin ileri bir hali: ürün ürün gelirlerini, kapattığı ve sattığı projeleri açıkça listeliyor. Kendini işten atılan ve sonra onlarca startup kuran biri olarak tanıtıyor. Buradan çıkarılacak ders "sen de gelirini yayınla" değil; çok sayıda küçük şeyi çıkarıp her birini anlatmanın zamanla kendi başına bir dağıtım kanalına dönüşebildiği.

Platform seçerken müşterin neredeyse oraya bak. Geliştiricilere satıyorsan X ve Hacker News; Türkiye'deki muhasebe bürolarına satıyorsan LinkedIn ve sektörel gruplar; tasarımcılara satıyorsan Instagram ve Dribbble daha mantıklı olabilir. Haftada bir düzenli güncelleme, her gün zorla yazılan beş paylaşımdan iyidir.

Gösteri moduna kayma

Laike9m yazısında çok basit bir gözlem yapıyor: herkes build in public yaptığında, aslında kimse yapmamış olur. Ona göre paylaşımların çoğu ürün fikri, plan ya da özellik yerine başarı ve övünme üzerine ve bu tekrar eden içerik takipçiye pek bir şey vermiyor. Ayrıca çok iyi yazılım yapan bazı geliştiricilerin neredeyse hiç build in public yapmadığını hatırlatıyor.

HN'deki yorumlarda da benzer bir eleştiri vardı: bazı insanlar ürünü yapmaktan çok build in public yaptıklarını duyurmaya zaman harcıyor. Cory Zue da kendi deneyiminde düzenli raporların zamanla rahat bir rutine dönüştüğünü, yeni fikir üretmeyi bıraktığını fark etmiş.

Kendine haftalık bir kontrol sorusu sor: "Bu hafta paylaşmak için mi çalıştım, yoksa çalıştığım için mi paylaşıyorum?" Cevap ilkiyse, bir hafta ara ver.

Bu hafta yapılacak

1. Müşterinin hangi platformda vakit geçirdiğini yaz ve paylaşımlarının ana yerini buna göre seç (X her zaman doğru cevap değil).
2. Paylaşmayacağın şeylerin listesini çıkar: müşteri isimleri (izinsiz), kanal bazlı gelir, rakibin kopyalayabileceği tarif.
3. Bu haftanın tek bir kararını ve gerekçesini 5–6 cümleyle paylaş.
4. Haftada bir sabit gün belirle ve 30 gün boyunca o gün kısa bir ilerleme notu yayınla.
5. Paylaşımlarına gelen her yorumu not al; hangisi gerçek müşteri profilinden, hangisi başka bir kurucudan geldi, ayır.

Sık sorulanlar

Gelir rakamlarımı paylaşmalı mıyım?

Zorunda değilsin. Tony Dinh gelir paylaşmanın ürüne güven verdiğini ama kopyacı çektiğini söylüyor; Cory Zue ise büyüdükçe bu yüzden bıraktı. Rakam yerine kararları ve dersleri paylaşmak çoğu durumda yeterli.

Hiç takipçim yok, kimse görmeyecekse neden yapayım?

Başlangıçta asıl fayda kitlede değil, hesap verebilirlikte. Levels'ın anlattığı gibi herkesin önünde olmak seni çalışmaya zorlar. Paylaşımların aynı zamanda ileride lansmanında gösterebileceğin bir arşiv olur.

Türkçe mi yazayım, İngilizce mi?

Müşterin kimse onun dilinde yaz. Türkiye'deki işletmelere satıyorsan Türkçe; global bir geliştirici aracı yapıyorsan İngilizce daha mantıklı. İkisini birden yapacaksan önce birinde düzen kur.

Fikrimi biri çalarsa?

Risk gerçek; Zue ve Dinh ikisi de kopyacılardan bahsediyor. Ama erken aşamada fikirden çok uygulama önemli. Yine de gizli tarifini, yani en kritik içgörünü kendine saklayabilirsin.

Dayanak

• Building a startup in public: from first line of code to frontpage of Reddit — Pieter Levels: Hoodmaps'in canlı yayında üretilmesi, faydaları (yardım, hesap verebilirlik, pazarlama) ve stresli yanları.
• Building in Public: What to Share at Which Stage of Your Journey — Arvid Kahl: aşamalara göre neyin paylaşılacağı ve paylaşmama hakkı.
• Farewell, Building in Public — Cory Zue: bırakma gerekçeleri (övünme hissi, kopyacılar, rakibe tarif verme, durağanlaşma) ve yöntemin kazandırdıkları.
• Tony Dinh on what he's learned as an indie developer — Product Hunt: X'te başlama, gelir paylaşmanın artısı ve eksisi.
• Marc Lou — kişisel site: ürün ürün açık gelir listesi ve çok sayıda küçük ürün yaklaşımı.
• No One Builds in Public — laike9m: yöntemin doygunluğu ve övünme içeriği eleştirisi.
• No One Builds in Public tartışması — Hacker News: kitlenin diğer kurucular olması tuzağı, Canny kurucusunun savunusu, rakamsız "garaj kapısı açık" yaklaşımı.
• "Build in Public" is the biggest lie indie hackers tell themselves — r/EntrepreneurRideAlong: build in public'in büyüme değil güven aracı olduğu görüşü, fikri mülkiyet riski.