Build in public nedir, nasıl başlanır?

Build in public ne demek?

Build in public, Türkçede "açıkta geliştirmek" ya da "herkesin gözü önünde inşa etmek" diye karşılanıyor. Ürünü aylarca sessizce yapıp bir gün vitrine koymak yerine mutfağı açıyorsun: bu hafta ne yaptın, hangi kararı neden verdin, neyi denedin de tutmadı, sırada ne var.

Her şeyi paylaşmak demek değil. Neyi göstereceğine sen karar verirsin; çoğu kurucu süreci, kararları ve öğrendiklerini paylaşır, hassas olanı kendine saklar. Reklam da değil. "Çok yakında harika bir şey geliyor" bir tanıtımdır; "kayıt formunu üç alandan bire indirdim, bakalım ne olacak" build in public'tir.

Neden yapılır?

• İlk kullanıcılar. Süreci izleyenler, ürün çıktığında çoğu zaman ilk deneyenler arasında olur. Kimse seni tanımıyorken bile her güncelleme işini birkaç kişinin daha önüne çıkarabilir.
• Erken geri bildirim. "Bunu neden böyle yaptın?" sorusunu lansmandan önce duyarsın. Bu, aylarca yanlış şeyi inşa etmekten çok daha ucuzdur.
• Hesap verebilirlik. Cuma günü bir şey yazacağını bilmek, haftayı boş geçirmeyi zorlaştırır. Yazmak için önce yapman gerekir.
• Güven. Aylarca istikrarla ilerleyen birini görmek, çoğu zaman cilalı bir landing page'den daha ikna edicidir.

Ne kadar açık olmalısın?

Açıklık bir yelpaze. Bir ucunda maaşlarını ve gelirlerini bile yayımlayan şirketler, öbür ucunda yalnız süreci ve kararları paylaşan kurucular var. Arvid Kahl önceki şirketinin gelirini açıkça paylaştı ve şirketin satışına giden ilginin bu görünürlükten geldiğini söylüyor. Nisan 2026'daki yazısında ise artık rakam paylaşmayacağını yazıyor: yapay zekâ kod ajanları, paylaşılan ayrıntıyı kopyalamayı çok hızlandırdı.

Upvera'nın kendisi de yapım sürecini Upvera'daki kendi startup sayfasında paylaşıyor: sürümler, lansmanlar ve etkinlikler oldukça oraya düşüyor, iş rakamları değil.

Ders şu: ne kadar açık olacağın bir tercih ve bu tercih zamanla değişebilir.

Nasıl başlanır?

Nerede paylaşmalısın?

Müşterin neredeyse oradan başla, kurucu kalabalığı neredeyse oradan değil: müşterilerinin zaten kullandığı sosyal ağ, sektörünün toplulukları, kendi blogun ya da bültenin. Tek yerde düzenli olmak, beş yerde ara sıra görünmekten iyidir. Günlük kaydın kendisi için Upvera tam bunun için yapıldı: her gün startup'ının sayfasında kalır, bağladığın kaynaklar işi kendiliğinden yazar.

Ne sıklıkla?

Sürdürebileceğin en sık ritim doğru ritimdir. Çoğu kişi için bu, hafta içi birkaç kısa not ve haftada bir toparlama yazısı demek. Bir yıl boyunca haftada bir yazmak, üç hafta her gün yazıp sonra kaybolmaktan iyidir.

İyi bir gönderide ne olur?

Dört parça yeter: ne yaptın, neden yaptın, ne oldu ya da ne öğrendin, sırada ne var. Elinden geliyorsa görsel ekle: ekran görüntüsü, kısa bir ekran kaydı, bir commit bağlantısı. Sona gerçek bir soru koyarsan cevap gelme ihtimali artar.

Örnek gönderi (uydurmadır, şablon olarak kullan):

Bu hafta fatura ekranını baştan yaptım. Kullanıcılar KDV alanında takılıyordu; artık alan kendiliğinden doluyor. İlk iki günde destek mesajları azaldı ama yabancı para birimi hâlâ bozuk. Sırada döviz desteği var. Sizce kuru kullanıcı mı girmeli, sistem mi çekmeli?

Basit bir haftalık ritim nasıl olur?

• Pazartesi: Bu hafta neyi bitirmek istediğini tek cümleyle yaz.
• Salı-perşembe: Günde bir kısa not: ne yaptın, bir ekran görüntüsü. Beş dakikayı geçmesin.
• Cuma: Haftanın özeti. Hedef neydi, ne oldu, ne öğrendin, haftaya ne var.
• Hafta sonu: Gelen yorumlara cevap ver. Build in public'in yarısı paylaşmak, yarısı konuşmaktır.

Neleri paylaşmamalısın?

Paylaştığın şey internette kalır; ekran görüntüsü alınır, arşivlenir. Göndermeden önce şu beş başlığa bak:

• Müşteri ve kullanıcı verisi. Ad, e-posta, telefon, adres ya da bir müşteriyi tanınır kılan küçük bir ayrıntı. 6698 sayılı KVKK'ya göre kimliği belirli veya belirlenebilir bir kişiye ait her bilgi kişisel veridir. En sık kaza, yönetim panelinin ekran görüntüsünde köşede kalan e-posta listesidir. Paylaşmadan önce bulanıklaştır ya da görüntüyü sahte veriyle al.
• Şifreler, API anahtarları, token'lar. Terminal çıktısında, .env dosyasında, adres çubuğunda saklanırlar. GitHub'ın belgesi, sızan bir anahtarda ilk adımın onu iptal etmek ya da yenilemek olduğunu, geçmişi temizlemenin başkalarının kopyalarından silmediğini söylüyor. Gönderide de aynısı geçerli: silmek yetmez, anahtarı yenile.
• Duyurulmamış anlaşmalar. Görüştüğün müşteri, imzalanmamış ortaklık, bir yatırımcıyla süren konuşma. Karşı taraf hazır değilken adını yazmak hem güveni hem anlaşmayı bozabilir.
• Pişman olacağın rakamlar. Gelir, müşteri sayısı, gider. Paylaşmak zorunda değilsin; paylaşacaksan düştüğünde de paylaşabileceğin bir rakam seç. Kahl'ın ölçütü işe yarar: insanların takip etmek isteyeceğini paylaş, seni kolay kopyalanır kılacak olanı sakla.
• Başkalarının bilgisi. Ekip arkadaşının hatası, eski ortağınla yaşadığın kırgınlık, bir müşterinin özel mesajı. Kendi hikâyeni anlat; onlarınki için izinleri gerekir.

Sık yapılan hatalar

• Yalnız başarıları paylaşmak. İnsanlar sorunla ve çözümle bağ kurar; her gönderi zafer duyurusuysa reklam gibi okunur.
• İşi değil emeği anlatmak. "Bugün çok çalıştım" bir şey söylemez; "ödeme akışındaki hatayı buldum" söyler.
• İlk haftadan kitle beklemek. İlk aylar neredeyse herkes için sessiz geçer.
• Her kanala aynı metni yapıştırmak. Farklı kanallardaki okurlar farklı şeyler bekler.
• Yorumlara cevap vermemek. Konuşmadan paylaşmak, duvara yazı yazmaktır.

Ne zaman işe yaramaz

Build in public bir dağıtım kanalı değil, bir alışkanlıktır; tek başına satış getirmez. Alıcın bu kanallarda değilse (örneğin hastanelerin satın alma birimleri), süreci izleyen kitle hiç müşterin olmayabilir. İşin gizliliğe dayanıyorsa (savunma, sağlık verisi, kopyalamanın hızlı olduğu bir pazar), açıklık riskini artırır. Yazmak düşünmene yardım etmek yerine seni tüketiyorsa ritmi küçült ya da bırak; ürün yine yapılır.

Sorular

Hiç takipçim yokken başlamanın anlamı var mı?

Var. İlk gönderilerini az kişi görür ama pratik kazanırsın ve geriye dönük bir iz bırakırsın. Biri ürününü üç ay sonra bulduğunda, o üç ayın kaydını okuyabilir.

Fikrimi çalarlar mı?

Risk gerçek: Kahl, yapay zekâ kod araçlarıyla bir ürünü kopyalamanın çok kolaylaştığını yazıyor. Bu yüzden mimarini, kullandığın servislerin listesini ve rakamlarını değil, süreci, kararları ve öğrendiklerini paylaş. Bunları kopyalamak daha zordur.

Türkçe mi İngilizce mi paylaşmalıyım?

Müşterinin dilinde. Türkiye pazarına satıyorsan Türkçe, global bir ürün yapıyorsan İngilizce. İkisine birden yöneliyorsan birini ana dil seç, ötekinde haftalık özet paylaş; iki dilde her gün yazmak çabuk yorar.

Gelir rakamlarını paylaşmak zorunda mıyım?

Hayır. Süreç rakamsız da anlatılır. "Bu hafta ilk ödeme yapan müşteri geldi" demek, tutarı yazmaktan daha az risklidir ve çoğu zaman yeterlidir.

Bu hafta gösterecek bir şeyim yoksa ne yazarım?

Takıldığın yeri, verdiğin bir kararı ya da vazgeçtiğin bir fikri yaz. "Bu hafta bir özelliği iptal ettim, nedeni şu" genellikle iyi bir gönderidir.

Upvera'da nasıl

Upvera, startup kurucularının ve bağımsız geliştiricilerin her gün ne inşa ettiklerini paylaştığı bir ilerleme platformu. Startup'ını eklersin, herkese açık bir sayfası olur; o gün ne yaptığını bir satırla yazarsın. GitHub, App Store, Vercel ya da npm bağlarsan push ve sürümler kaynaktan okunup günlerine kendiliğinden eklenir. Günler yalnızca ekleme yapılan bir deftere mühürlenir, günlük kökler OpenTimestamps kanıtıyla herkese açık bir GitHub deposunda yayımlanır ve isteyen upvera.co/dogrula adresinde kontrol edebilir. Topluluk gönderilere Prime ("ilgimi çekiyor, ileri taşınsın") ya da Pass ("bana göre değil") ile karşılık verir. Startup'ını ekle ya da Upvera'nın kendini nasıl inşa ettiğine bak.

Kaynaklar

• Arvid Kahl: The Increasing Risk of Building in Public (Nisan 2026)
• GitHub Docs: Removing sensitive data from a repository
• 6698 sayılı Kişisel Verilerin Korunması Kanunu (mevzuat.gov.tr)