İçeriğe geç
Kilavuz
Blog

ürün

starlightBlog.tags.count

Kilavuz Bugün Yayında

Kilavuz
Kilavuz

Kilavuz’un ilk sürümünü bugün yayınladık. Bu yazı, ürünün hangi parçalarla doğduğunu ve bizi izleyen birkaç hafta içinde nelerin geleceğini özetliyor.

Ne yapar?

Kilavuz, hiyerarşik soru listelerini tasarlayıp Markdown’a aktarmanız için tasarlanmış bir üründür. Tipik bir kullanım şöyle akar:

  • Ekipteki herkes aynı proje altında soruları düzenler.
  • Bir kök sorunun altına sınırsız derinlikte alt sorular eklenebilir.
  • Sorular sürüklenip bırakılarak yeniden sıralanır.
  • Son hali geldiğinde, ağaç tek bir Markdown dosyası olarak indirilir.

Bu akış özellikle röportaj taslakları, retrospektifler, keşif notları ve QA kontrol listeleri için işe yarıyor; biz de kendi çalışmalarımızda bu yüzden kullanıyoruz.

Bugünkü sürümde neler var?

  • Üç plan: Ücretsiz, bireysel ve ekip. Plan karşılaştırması fiyatlandırma sayfasında var.
  • Soru ağacı düzenleme: Sürükle-bırak yeniden sıralama ve yumuşak silme. Silinen bir soru, altındaki soruları yetim bırakmaz.
  • Markdown’a aktarma: Ağacın tamamı hiyerarşik numaralandırma ile birlikte tek dosyada indirilir. Uç noktanın ayrıntıları API referansında var.
  • Yönetim paneli: Kullanıcı yönetimi, faturalama görünümü ve denetim kayıtları. Yalnızca yöneticilere açıktır.
  • Çerez onayı ve dil seçimi: Türkçe varsayılan, İngilizce kullanılabilir; seçim tarayıcıda saklanır.

Nereden başlarsınız?

  1. https://kilavuz.app adresine gidin ve Kayıt ol ile bir hesap açın.
  2. Başlangıç rehberindeki adımları takip ederek ilk soru ağacınızı kurun.
  3. Bir sorunuz olursa bu blogdaki yorumları ya da e-posta yoluyla bize ulaşın.

Sırada ne var?

  • Ekip içi işbirliği: Birden çok kişinin aynı ağaç üzerinde eşzamanlı çalışması için çakışma çözümü.
  • Şablonlar: Sık kullanılan soru ağaçları için başlangıç şablonları (mülakat, retrospektif, keşif).
  • Dışa aktarma genişletmesi: Markdown’a ek olarak JSON ve OPML formatlarında dışa aktarma.

Bu yol haritası, ürünü kullanan ilk ekiplerden gelen geri bildirimlerle şekillenecek. Geri bildirimlerinizi blog yorumları üzerinden veya hello@kilavuz.app üzerinden bekliyoruz; yanıt süremiz, kaç kişi yazdığına bağlı olarak değişebilir.

Kilavuz Neden Var

Kilavuz
Kilavuz

Bu yazı, Kilavuz’un hangi sorunu çözmek için doğduğunu ve tasarım kararlarının nedenlerini anlatıyor. Ürün sayfasındaki özellik listesinden farklı olarak, burada “neden” kısmına odaklanıyoruz.

Çıkış noktası

Bir ekip içinde yapılandırılmış notlar tutmak istediğinizde elinizde iki yaygın seçenek var:

  • Belge düzenleyici: Serbest metin olarak soruları alt alta yazarsınız; hiyerarşi görsel olarak bozulur, yeniden sıralamak zahmetlidir.
  • Proje yönetim aracı: Her soru bir “ticket” olur; bu sefer ağaç yapısı kaybolur, bilgi dağılır.

Bu iki uç arasında kalan bir boşluk var: hiyerarşiyi koruyarak serbest metin yazmak, taşımak ve başka formatlara dönüştürmek. Kilavuz, bu boşluğu doldurmak için doğdu.

Tasarım ilkeleri

Ürünü tasarlarken üç ilkeye bağlı kaldık:

  1. Veri yapısı önce: Hiyerarşi, kullanıcının gözünden değil, veritabanının gözünden birinci sınıf bir yapı. Bu yüzden parentId, sortKey ve depth alanları modelin temelinde yer alıyor.
  2. Yumuşak silme: Bir soruyu silmek, altındaki bilgiyi kaybetmeniz anlamına gelmemeli. softDeleteQuestion eylemi, alt soruları yetim bırakmadan hedef kaydı damgalar.
  3. Sahip olunan tek dışa aktarma formatı: Markdown, ekibimizin ve müşterilerimizin zaten bildiği bir format. JSON ve OPML yol haritasında; ilk günden itibaren ek bir biçim yükü getirmedik.

Türkçe neden varsayılan?

Ekibimiz Türkçe konuşuyor; müşterilerimizin önemli bir kısmı da Türkçe çalışıyor. Ürünün Türkçe varsayılanla doğması, kendi işimizi yaparken en az dirençle karşılaşmak anlamına geliyordu. İngilizce seçeneği, gerçek bir eksiği kapatmak için değil, ürünü uluslararası kullanıma açık tutmak için eklendi. Dil seçimi, bir veri olarak değil, bir UI tercihi olarak saklanıyor; bu sayede sunucu tarafı verileri dil-agnostik kalıyor.

Neyi özellikle yapmadık?

  • SDK form kontrollerini Türkçeye çevirmedik. Wasp SDK’sının iç form bileşenleri İngilizce kalır; bu istisna bilinçli bir kapsam kararıdır.
  • Sunucu hata iletilerini çevirmedik. API hata gövdeleri İngilizce kalır; bunlar geliştiriciye yöneliktir.
  • Kişiselleştirilmiş bir fatura şablonu yazmadık. PDF faturalar, Stripe’ın şablonundan alınır.

Bu “yapmadık” listesi, kapsamımızın sınırlarını netleştiriyor. Ürünü kullanırken bir sınırla karşılaşırsanız, bunun bilinçli bir karar mı yoksa eksik bir özellik mi olduğunu sormak için bize ulaşabilirsiniz.

Bundan sonra

Önümüzdeki aylarda ürünü gerçek kullanım verileriyle şekillendireceğiz. Yol haritasını ve değişiklik günlüklerini blog üzerinden paylaşmaya devam edeceğiz.