SignaFlow’u Neden Durdurdum: Ürünü İnşa Etmeden Önce Entegrasyonu Doğrulayın

SignaFlow’un vaadi netti. Bir şirket bütün e-posta imzalarını tek bir panelden yönetecek, güncellemeler de kimseden HTML kopyalayıp yapıştırması istenmeden yayılacaktı. Bu vaadin en zor parçasını doğrulamadan önce ürünün görünen kısmının büyük bölümünü inşa ettim. Kurulum yolunu sonunda test ettiğimde, ürünün dayandığı merkezi ve otomatik davranışı sağlayan desteklenen bir API akışı bulamadım.

Proje 18 Ekim 2025’te durduruldu. Kod hâlâ herkese açık, çünkü geriye kalan asıl işe yarar şey ürün değil, yaptığım hata :)

Önce ne inşa ettim

Repo, şunları içeren bir React ve TypeScript frontend barındırıyor:

• bir panel ve çalışan yönetimi;
• üç imza şablonu;
• kampanya alanları ve ayarlar;
• yapılandırılabilir bir n8n webhook istemcisi;
• HTML ve düz metin imzalar döndüren bir n8n workflow’u.

Belgelenen son akış şöyle görünüyordu:

React frontend → n8n webhook → generated signature → manual copy/paste

Bu akış bir imza üretebiliyordu ancak vaat imza üretmek değildi; imzanın merkezden kurulmasıydı.

Çok geç test ettiğim varsayım

E-posta istemcisi entegrasyonunu bir uygulama detayı sandım. Oysa ürünün ayakta kalıp kalamayacağını belirleyen asıl risk oydu.

Doğru ilk kilometre taşı bir panel değildi; dar kapsamlı bir kanıt olmalıydı:

1. bir hedef istemci ve hesap türü seçmek;
2. desteklenen bir entegrasyon üzerinden bir imzayı kurmak veya güncellemek;
3. bunu ikinci bir çalışan için tekrarlamak;
4. hangi izinlerin ve yönetici kontrollerinin gerektiğini doğrulamak;
5. akışın hâlâ hedeflenen müşteri deneyimiyle örtüştüğünü teyit etmek.

Bu kanıt ilk günden başarısız olsaydı, proje frontend ivme kazanmadan önce yön değiştirebilirdi.

Manuel kopyala-yapıştır neden yetmedi

Manuel teslimat geçerli bir ürün olabilir; tutarlı şablonlar, önizlemeler ve talimatlar sağlayabilir. Ancak inşa etmeyi amaçladığım ürün bu değildi.

Orijinal değer önerisi, tekrarlayan çalışan eylemini ortadan kaldırmaya dayanıyordu. Kalan iş akışı her kişinin kendi çıktısını kurmasını gerektirince ürün, farklı rakiplerin olduğu ve var olma sebebi daha zayıf bir kategoriye geçti. Bu ayrım önemli: çalışan bir yedek plan, orijinal vaadin otomatik olarak geçerli bir alternatifi olmuyor.

İşe yarayan kısımlar bile eksikti

Frontend mock veya yerel state kullanıyordu; Supabase entegrasyonu, kimlik doğrulama ve production dağıtımı tamamlanmamıştı. n8n dokümantasyonu da webhook kimlik doğrulamasını ve rate limiting’i sonraya bırakmıştı. Bunlar çözülebilir mühendislik görevleriydi ancak çözmek doğrulanmamış kurulum modelini onarmayacaktı. Görünür arayüz bitmeye yakın göründüğü için devam etmek, ürün riskini azaltmak yerine batık maliyeti korurdu.

Ders: işi belirsizliğe göre sıralayın

Entegrasyon ağırlıklı ürünler için artık ilk haftanın, fikri öldürebilecek soruları cevaplamasını istiyorum:

• Gereken API, tam olarak o müşteri ve hesap türü için var mı?
• İlgili veriyi döndürmekle kalmayıp kritik eylemi gerçekleştirebiliyor mu?
• Hangi izinler, incelemeler veya yönetici rolleri gerekiyor?
• Yedek plan, orijinal değer önerisini koruyor mu?
• Kanıt, arayüz inşa edilmeden önce gerçek bir hesaba karşı çalıştırılabilir mi?

Arayüz tarafı öngörülebilir ilerler; dış politikalar ve entegrasyon kısıtları ise öyle değildir. En erken test edilmesi gereken, belirsiz olan taraftır.

Durdurmak, inşa etmenin bir parçasıydı

SignaFlow, merkezi imza araçlarının her koşulda imkânsız olduğunu göstermedi. Yalnızca hedeflediğim entegrasyon yolunun, tasarladığım otomatik davranışı taşımadığını gösterdi. Bu daha dar sonuç aslında daha işe yarar, çünkü somut bir süreç değişikliğine işaret ediyor: önce en riskli entegrasyonun kanıtını çıkarın, paneli yazma hakkını sonra kazanın.

Arşivlenen uygulama ve durumu SignaFlow repo’sunda belgeleniyor; buna n8n workflow rehberi ve dağıtım notları da dahil.