@bberber

Bu projeyi yapabilirsin, ama önce şunu netleştirelim: Claude aboneliği bu işin en ucuz ve en az kritik parçası. Asıl mesele neyi zincire koyacağına karar vermek. Ben benzer bir şeyi geçen yıl bir arkadaşın oyunu için kurdum, o tecrübeyle uzun uzun yazayım, sonra kısaltırsın.

Üyelik meselesinden başlayayım. Bir web oyununa cüzdan bağlamak ve ödül dağıtmak için Claude'un ücretsiz sürümü bile bir yere kadar götürür, ama gerçekten haftalarca kod yazacaksan Pro almak mantıklı; asıl fark Claude Code kullanabilmek, çünkü Anchor projesinde dosyalar arası bağlamı elle kopyalayıp yapıştırmak bir süre sonra çekilmez oluyor. Seyrek kullanacaksan API üzerinden kullandıkça öde daha ucuza geliyor, konsoldan 5 dolar yükleyip başlıyorsun. Ama şunu bil: model sana Anchor kodu yazar, testleri de yazar, yine de PDA seed'lerini, bump'ları ve account constraint'lerini satır satır kendin okumak zorundasın. Solana'da hataların çoğu "unutulan bir has_one" ya da "signer kontrolü olmayan bir hesap" kadar küçük şeylerden çıkıyor ve model bunları özgüvenle atlıyor. Anchor sürümünü prompt'un başına yaz (0.29 ile 0.30 arasında API değişti, model eski sürümü karıştırıyor), ilk iş olarak test yazdır, anchor test ile localnet'te çalıştırmadan hiçbir kodu doğru sayma.

Mimariye gelince, üç parça var. Ön yüzde Next ya da düz React ile @solana/wallet-adapter kullan, Phantom dahil bütün cüzdanlar oradan geliyor, kendin Phantom'a özel bir şey yazma. Cüzdanı bağlamak kimlik doğrulama değildir; oyuncunun gerçekten o cüzdanın sahibi olduğunu anlamak için Sign In With Solana ile bir mesaj imzalat, sunucuda imzayı doğrula, sonra oturum aç. Bunu atlayan projeler "cüzdan adresini bilen herkes hesabıma giriyor" sorununu yaşıyor. İkinci parça oyun sunucusu; oyunun kendisi zincirde çalışmasın, puanlar, seviyeler, hile kontrolü hepsi senin veritabanında dursun. Üçüncü parça Anchor programı; sadece token mint'i ve ödül dağıtımı orada olsun. Zincire ne kadar az şey koyarsan o kadar az şey audit ettirirsin, o kadar az yerden vurulursun.

Ödül akışı için iki yol var, ikisini de yaşadım. Birincisi sunucu imzalı claim: oyuncu ödül kazanınca sunucun bir mesaj imzalıyor (miktar, cüzdan, nonce), oyuncu bu imzayı programa götürüyor, program ed25519 doğrulamasıyla imzayı kontrol edip mint ediyor. Basit, her ödül anında akıyor, ama her claim bir işlem demek ve oyuncu ilk seferinde token hesabı (ATA) açmak için 0,002 SOL civarı rent ödüyor. Bunu kim ödeyecek sorusunu baştan cevapla; oyuncuya ödetirsen ilk günden kaybedersin, kendin ödersen bütçele. İkinci yol Merkle distributor: ödülleri gün sonunda toplayıp bir Merkle ağacına yazıyorsun, kökü zincire tek işlemle koyuyorsun, oyuncular isterse claim ediyor. Jupiter ve birçok airdrop bunu kullanıyor, hazır açık kaynak programı var, ücret maliyeti çok düşer ve "ödül otomatik aksın" isteğin sadece bir günlük gecikmeyle karşılanmış olur. Yeni başlayan bir oyun için benim tavsiyem ikincisi; oyuncuya anlık his vermek istiyorsan arayüzde bakiyeyi hemen göster, zincire toplu yaz.

Token tarafında SPL token yeterli, Token-2022'nin transfer fee ve metadata gibi özelliklerine ihtiyacın yoksa oraya girme, cüzdan ve borsa desteği hâlâ eksik. Mint authority'yi kendi cüzdanında tutma, programın bir PDA'sına ver; yoksa "kurucu istediği kadar basar" eleştirisini ilk gün yersin. Ekonomiyi de düşün: sınırsız basılan ödül token'ı üç ayda sıfıra gider, bunu gören yüzlerce oyun var. Ya sabit arz ve azalan ödül eğrisi ya da ödülün bir kısmının oyun içinde yakılması gerekiyor. Bir de Türkiye'de bunun hukuki tarafı var; token dağıtan bir oyun kripto varlık düzenlemesinin ve MASAK'ın radarına giriyor, en azından bir kez bilen birine danış.

Phantom'a özel bir uyarı: yeni alan adları Phantom'un kimlik avı listesine kolayca takılıyor ve kullanıcıya kırmızı ekran çıkıyor. Alan adını Blowfish'e bildir, sitenin metadata'sını düzgün kur, imzalatacağın işlemlerin simülasyonda ne yaptığı okunabilir olsun. Devnet'te haftalarca test et; devnet SOL için faucet var, mainnet'e geçişi son ana bırak.

Audit sorusuna gelince, dürüst cevap şu: gerçek bir audit ücretsiz değil. OtterSec, Neodyme, Sec3 gibi ekipler küçük bir program için bile on binlerce dolar istiyor. Ama ücretsiz yapabileceklerin var ve bunlar çoğu hobi projesinin hiç yapmadığı şeyler. Sec3'ün X-Ray tarayıcısının ücretsiz katmanı Anchor programını statik olarak tarayıp bilinen kalıpları buluyor; cargo audit bağımlılıkları kontrol ediyor; Anchor'un kendi constraint sistemi doğru kullanıldığında en yaygın hataların yarısını zaten engelliyor. Coral'ın sealevel-attacks deposu Solana'ya özgü saldırı sınıflarını (signer kontrolü, owner kontrolü, type cosplay, reinitialization, arbitrary CPI, bump seed canonicalization) çalışan örneklerle anlatıyor; kendi programını o listeye karşı tek tek gözden geçir. Neodyme'nin Solana security workshop'u da açık, bir hafta sonunda bitiyor ve auditörlerin nereye baktığını öğretiyor. Bunları yaptıktan sonra kodu Superteam Türkiye'nin geliştirici kanallarında paylaşırsan gönüllü göz atan çıkıyor, ben de bakarım. Grant alırsan Solana Foundation'ın audit sübvansiyonu programı var, orası tek gerçek "ücretsiz audit" yolu. Yayına aldıktan sonra da küçük bir bug bounty koy; Immunefi'ye girmek için büyük olmak gerekmiyor, kendi sitende bin dolarlık bir ödül bile ciddi göz getiriyor.

Son bir şey: Claude'a "bana güvenli bir Solana ödül programı yaz" dersen sana güzel görünen ve muhtemelen bir yerinden delik bir program yazar. Ona "bu programda hangi hesap kimin tarafından imzalanmalı, hangi hesabın owner'ı kontrol ediliyor, reinitialization nasıl engelleniyor" diye tek tek sordurursan çok daha işe yarar. Modeli kod yazıcı değil, sabırsız ama bilgili bir eş programcı gibi kullan. Repo'yu açarsan buraya link bırak, ilk sürümüne birlikte bakalım.

Sıralamaya katılıyorum ama web sitesini beşinci sıraya koymana itiraz edeceğim.

Müşteriniz sizi bulamıyorsa diğer sistemlerin bir anlamı yok.

Bizim sektörümüzde müşteriler arama yaparak geliyor ve site olmadan hiç görünmüyorduk.

Bence sıralama sektöre göre değişmeli. Müşteriniz sizi nereden buluyorsa oradan başlamak gerekiyor.

Zaten müşterisi olan ve iç düzeni bozuk bir işletmede sizin sıralamanız doğru. Müşteri bulmakta zorlanan bir işletmede site öne gelmeli.

Hata çıkınca önce testini yazma kuralı en verimli yaklaşım, bunu herkes uygulamalı.

Sebebi şu: o test kesinlikle gerçek bir senaryoyu koruyor. Hayali senaryolar için yazılan testlerin çoğu hiçbir şey yakalamıyor ve bakım yükü getiriyor.

Bir ekleme: testi yazdıktan sonra düzeltmeden önce çalıştırın ve kırmızı olduğunu görün. Yeşil çıkıyorsa yanlış şeyi test ediyorsunuz demektir.

Bu adımı atlayan çok kişi var ve hiçbir şey test etmeyen testler yazılıyor.

Kısmen katılıyorum ama bir noktayı düzeltmek isterim. Geri ödemeli destek kredi gibi düşünülmeli denmiş, tam olarak öyle değil.

Faizsiz ve uzun vadeli olması ciddi avantaj. Bankadan alacağınız kredi ile karşılaştırınca arada büyük fark var.

Ama şu doğru: geri ödemeli kısmı bedava para sanıp bütçe yapanlar sonra zorlanıyor. Geri ödeme takvimi işletmenin nakit akışıyla örtüşmüyorsa sıkıntı çıkıyor.

Başvuru öncesi geri ödeme takvimini tabloya dökmek gerekiyor.

Sır yönetimi konusuna bir ekleme yapayım çünkü sızdıktan sonrası yanlış yönetiliyor.

Anahtar depoya düştüğünde insanlar yeni bir kayıt atıp siliyor. Ama geçmiş kayıtlarda duruyor ve erişilebiliyor.

Doğru davranış, anahtarı derhal iptal edip yenisini üretmek. Silme işlemi ikincil.

Bir de anahtarları uzaktan değiştirilebilir hale getirmek önemli. Yeni sürüm çıkarmadan anahtar değiştirebiliyorsanız, olay anında dakikalar içinde müdahale edebiliyorsunuz.

Başarı oranını en üste koyman çok doğru, bu en az bilinen ama en pahalı kalem.

Bizde iki sağlayıcı arasında birkaç puanlık fark vardı ve yıllık tutara vurunca komisyon farkının katları çıktı.

Ölçerken dikkat: başarısız işlemleri sebebine göre ayırmak gerekiyor. Yetersiz bakiye sizin sorununuz değil, ama teknik red sağlayıcının sorunu.

Sadece teknik redleri karşılaştırmak lazım, toplam başarı oranı yanıltıcı olabiliyor.

Sayının yanına cümle ekleme kısmı bizde de dönüm noktasıydı.

O cümleyi yazmak bir insanın işi ve otomatikleştirilemiyor. Ama en çok değeri o yaratıyor çünkü yorumlama işini okuyucudan alıyorsunuz.

Bir ekleme: cümlede sadece ne olduğunu değil, ne yapılması gerektiğini de yazmak daha etkili oluyor.

Şu düştü demek bilgi, şu düştü çünkü bu oldu, şunu yapmamız gerekiyor demek karar.

Tabii bunu yazabilmek için işi anlamak gerekiyor. Veri ekibinin iş bilgisi burada devreye giriyor.

Üç müşteri sınırına katılmıyorum, bu işin türüne çok bağlı.

Ben küçük ve kısa işler yapıyorum. Aynı anda altı yedi müşterim olabiliyor ama her biri haftada birkaç saat.

Sizin anlattığınız büyük ve süregelen projeler için sınır mantıklı.

Bence asıl ölçüt müşteri sayısı değil, aktif bağlam sayısı. Aynı anda kaç farklı problemi zihninizde tutuyorsunuz?

Benim işlerim birbirine benziyor, bağlam maliyeti düşük. Farklı sektörlerde çalışsam üçü bile fazla gelirdi.

Nakit dönüşüm süresini listeye almanız çok doğru, bu en az anlaşılan ama en tehlikeli kalem.

Kârlı ama nakitsiz şirket batabiliyor. Ciro rekoru kırarken maaş ödeyememek mümkün.

Süreyi kısaltmak için üç kaldıraç var: stok süresini kısaltmak, tahsilatı hızlandırmak, tedarikçiye ödemeyi geciktirmek.

Üçüncüsü etik sınırlar içinde ve anlaşmalı yapılmalı, tedarikçiyi zor durumda bırakmak uzun vadede zarar veriyor.

İlk ikisi üzerinde çalışmak daha sağlıklı.

Kişisel kefalet konusunu vurgulamak isterim, bu en hafife alınan risk.

Limited şirket kurmanızın sebebi sorumluluğu sınırlamak. Kişisel kefalet verince o koruma kalkıyor.

Bankalar küçük işletmelerden neredeyse her zaman kefalet istiyor ve pazarlık alanı sınırlı.

Ama en azından kapsamı daraltmaya çalışmak mümkün. Süre sınırı, tutar sınırı veya belirli varlıkla sınırlama.

Sözleşmeyi imzalamadan önce bir hukukçuya okutmak, ödenen ücrete değiyor.

Güven açığı meselesini çok doğru tespit etmişsin, bizde de en çok emek verdiğimiz konu buydu.

Bizde işe yarayan somut şeyler: kurucu olarak kendi adımla yazdığım bir blog, müşteri görüşmelerini yüz yüze video ile yapmak ve destek taleplerine iki saat içinde dönmek.

İkinci madde beklenmedik şekilde etkili oldu. Karşınızdakinin yüzünü görmek, bilinmeyen bir ülkeden geliyor olmanın yarattığı mesafeyi kapatıyor.

Bir de şirket adresini ve gerçek iletişim bilgisini sitede göstermek. Saklayan siteler şüphe uyandırıyor.

Tam olarak öyle. Bizde de kurtarıcı olan şey, raporu insanların çalıştığı yere göndermek oldu.

Panoya git demek, insanlardan alışkanlık değiştirmelerini istemek demek. Kimse yapmıyor.

Bir de şu işe yaradı: özet mesajın içine bir yorum satırı ekledik. Sadece sayı değil, bu hafta şu düştü çünkü şu oldu gibi bir cümle. Sayıyı okumak zorunda kalmadan durumu anlıyorlar.

O cümleyi yazmak bir insanın işi ve otomatikleştirilemiyor ama en çok değeri o yaratıyor.

Para alanı konusunda sonuna kadar haklısın, bu klasik ve pahalı bir hata.

Ondalıklı sayı tipi finansal hesaplama için uygun değil. Küçük yuvarlama farkları binlerce işlemde toplanınca mutabakat tutmuyor.

Bizde muhasebe ekibi aylarca fark arıyordu, sebebi buydu.

Çözüm olarak kuruş bazında tam sayı tutmaya geçtik. Görüntüleme sırasında bölüyoruz.

Geçiş acı verici oldu ama artık kuruş kuruşuna tutuyor.

Ölçüm kesinliğinin azalması konusunda bir şey eklemek isterim.

Ekipler artık raporlardaki sayıları mutlak doğru kabul etmemeli. Modelleme var ve tahmin payı içeriyor.

Bizde işe yarayan yaklaşım, platform raporlarını tek başına kullanmamak. Kendi arka uç verimizle karşılaştırıyoruz.

İki kaynak arasında sürekli bir fark var ve o farkın oranını biliyoruz. Kararları buna göre düzeltilmiş rakamlarla alıyoruz.

Mükemmel değil ama körü körüne rapora güvenmekten iyi.

Kohort bakmadan kayıp ölçmenin yanıltıcı olduğu tespiti çok doğru, bu klasik bir hata.

Büyüyen bir şirkette toplam oran hep iyi görünüyor. Büyüme yavaşladığı gün gerçek tablo ortaya çıkıyor ve o zaman geç oluyor.

Bir ekleme: kayıp oranını sözleşme süresine göre de ayırın. Aylık ödeyenler ile yıllık ödeyenler çok farklı davranıyor.

Yıllık ödeyende kayıp geç görünüyor ama yenileme zamanında toplu geliyor. Bunu öngörmek için yenileme takvimini takip etmek gerekiyor.

Açık kaynak lisans envanteri tutma tavsiyesini desteklerim, bu konuda otomatik araçlar var.

Bağımlılıkların lisanslarını tarayıp raporlayan araçlar sürekli entegrasyon hattına eklenebiliyor.

Yeni bir bağımlılık eklendiğinde lisansı kontrol ediliyor ve uyumsuzsa uyarı veriyor.

Bir de dolaylı bağımlılıkları unutmayın. Kullandığınız kütüphanenin kullandığı kütüphane de kapsamda.

Bu kontrolü kurmak yarım günlük iş ve ileride çok baş ağrısı önlüyor.

Tekrarlayan geliri bileşenlerine ayırma kısmı en değerli madde bence.

Toplam büyüme rakamı çok şey gizliyor. Yeni müşteri getiremiyor olabilirsiniz ama mevcut müşteriler büyüdüğü için toplam artıyor görünebilir.

Bu iki durum tamamen farklı stratejiler gerektiriyor.

Bir ekleme: mevcut müşteri büyümesi kayıptan fazlaysa, hiç yeni müşteri almasanız bile büyüyorsunuz demektir. Bu çok güçlü bir konum ve ayrıca takip edilmeli.

Mevcut maliyeti ölçme kısmı bence işin en zor ama en değerli parçası.

Çoğu kurumda bir sürecin gerçekte ne kadar tuttuğunu kimse bilmiyor. Ölçtüğünüzde ortaya çıkan sayı herkesi şaşırtıyor ve o şaşkınlık tek başına bütçe açıyor.

Ölçerken dikkat: sadece doğrudan maliyeti değil, o işi yapan kişilerin başka bir şey yapamamasını da hesaba katın.

Bir de hata maliyeti. Süreçte oluşan hataların düzeltilmesi genelde en büyük kalem çıkıyor ve hiç kaydedilmiyor.

Sahip olduğunuz tek kanal vurgusu doğru ama tek başına yeterli değil, bir şey daha eklemek isterim.

Teslim edilebilirlik. Listeniz sizin ama kutuya düşüp düşmeyeceği sizin elinizde değil.

Bunun için alan adı doğrulama kayıtlarını düzgün kurmak gerekiyor. Bunlar yoksa gönderimleriniz gereksiz klasörüne düşüyor.

Bir de liste hijyeni. Açmayan adresleri temizlemek, teslim edilebilirliği koruyor.

Satın alınmış liste kullanmak ise en hızlı itibar öldürme yolu.

Erken durdurma hatasını çok iyi yakalamışsın, bu en yaygın ve en pahalı hata.

İnsanlar günlük sonuçlara bakınca dayanamıyor. Çözüm olarak biz test süresince sonucu kimseye göstermiyoruz. Sadece zarar kontrolü metriklerine bakılıyor.

Kulağa sert geliyor ama merakı ortadan kaldırdı ve testler düzgün tamamlanmaya başladı.

Bir de gerekli örneklem büyüklüğünü önceden hesaplamak şart. Bunu yapmadan başlayan testlerin çoğu, sonuç çıkaramayacak kadar küçük trafikle yürüyor.

İnternette ücretsiz hesaplayıcılar var, beş dakikalık iş.