Geçen yıl Kasım ayında, İstanbul’da bir akşamüstü — elinde kahve, önünde boş bir not defteri — şunu düşündüm: Aynı altyapıyla iki ayrı SaaS ürün çıkarılabiliyorsa, asıl mesele fikir mi, yoksa o fikirden önce gelen mühendislik kararları mı? İşte bu soru beni hep dürttü, yani gerçekten içimde bir yerde takılı kaldı. Bir yanda AI destekli özgeçmiş düzenleyici, öbür yanda bambaşka bir şey… fatura üreten bir araç. Kağıt üstünde küçük iş gibi duruyor. Ama pratikte bayağı öğretici çıktı.
Orijinal fikir basitti. Kullanıcı düz metin yazacak, sistem bunu okuyup profesyonel bir PDF faturaya çevirecek — ne Excel dosyası, ne şablon uğraşı, ne de “şunu nereye yazıyorduk?” paniği. Açık konuşayım, ben bu tür ürünleri seviyorum; çünkü küçük ama net bir acıyı çözüyorlar, hem de hızlı. Gösterişsiz. Sessiz sedasız çalışıp hayat kurtaran türden.
Evet, doğru duydunuz.
Bu yazıda sana o haftalık inşa mantığını kendi gözümden anlatacağım. Sadece teknik tarafı değil; neden bu yaklaşımın işe yaradığını, nerede tökezlediğini ve küçük ekiplerle kurumsal ekiplerin neden aynı çözümü aynı şekilde kullanmadığını da konuşacağız. Hazırsan başlayalım.
Neden Fatura Üreticisi?
İtiraf edeyim, Şimdi bakın, iyi bir SaaS fikri ararken çoğu kişi büyük görünmeye çalışıyor. Oysa bazen en iyi test alanı küçücük bir problem oluyor — fatura üretimi tam da öyle. Kullanıcıya doğrudan değer veriyor, karar verme süresi kısa, çıktısı ölçülebilir. Ve en önemlisi MVP için fazla şişkin değil (şaşırtıcı ama gerçek)
Buna benzer bir durumu 2024 Mart’ında Kadıköy’de çalışan küçük bir ajans için gözlemlemiştim. Ekipteki iki kişi her hafta aynı faturayı yeniden dolduruyordu; müşteri adı değişiyor, saatler değişiyor, oranlar değişiyor… yani resmen kopyala-yapıştır cehennemi. Bu tip işlerde otomasyon çok havalı görünmüyor belki. Ama zaman kazandırıyor. Hem de kimse fark etmeden.
Çok konuştum, örnekle göstereyim.
Dur bir saniye, şunu da söyleyeyim: burada asıl başarı “AI koyduk” demek değil. Başarı, kullanıcıya güven veren basitlikte kalmak. Çünkü muhasebe tarafında insanlar gösterişli arayüz değil, hata yapmayan akış istiyor. Bu fark önemli. Siz hiç denediniz mi? Gerçekten önemli.
İki Katmanlı Ayrıştırma Mantığı
İşin kalbi metni anlamakla başlıyor. Kullanıcı “Acme için 10 saatlik iş, saatlik £100” yazdığında sistemin bunu üç parçaya ayırması lazım: müşteri adı, süre ve ücret. İlk bakışta basit. Bu ne anlama geliyor? Ama doğal dil dediğimiz şey biraz huysuzdur — herkes aynı cümleyi aynı biçimde kurmuyor, bunu unutmamak lazım (ciddiyim)
Bu yüzden tek başına yapay zekâya abanmak yerine iki katmanlı yapı daha mantıklı geliyor bana. Önce hızlı ve ucuz yol deneniyor; regex yani kalıp yakalama devreye giriyor. Oradan sonuç çıkarsa işlem tamam, bitti, geçtik. Çıkmazsa ikinci kapı açılıyor ve model yardımı alınıyor.
Neyse uzatmayalım: bu yaklaşım bana mutfakta çay demlemeyi hatırlatıyor. Önce su kaynar mı diye bakarsın; olmadı kettle’ı tekrar çalıştırırsın (ciddiyim). Her şeyi direkt robot koluna bırakmak gerekmiyor. Gerekmez de zaten. Daha fazla bilgi için Mülakatta Çaktırılan 7 Yazılımcı Hatası: Kaçın yazımıza bakabilirsiniz.
| Aşama | Ne yapıyor? | Artısı | Eksiği |
|---|---|---|---|
| Regex | Düzenli kalıpları yakalıyor | Hızlı, ucuz, tahmin edilebilir | Karmaşık ifadelerde kaçırabiliyor |
| AI fallback | Anlamdan yapı çıkarıyor | Daha esnek | Maliyet ve gecikme ekliyor |
Regex neden hâlâ önemli?
Araya gireyim: Bence regex’in değeri tam da sıkıcı olmasında yatıyor. Evet, yanlış duymadın. Her şeyi çözmez, bunu biliyoruz. Ama bildiğin senaryolarda taş gibi çalışır — en azından ben öyle düşünüyorum — — “Invoice Acme for 10 hrs at £100/hr” gibi bir cümleyi anında ayrıştırınca API çağrısı bile yapmadan sonuca ulaşırsın. Temiz.
Bunu ilk kez 2023 sonbaharında Ankara’daki freelance işlerimde denemiştim; çok benzer bir metin ayrıştırıcıda yüzde 70-80 isabet oranını yalnızca kalıp tanımlarıyla yakalamıştım. İnsanlar genelde bunun modası geçmiş olduğunu düşünüyor. Değil. Sadece gösterişsiz. SonarQube mu PMD mi? Java Kodunu Kurtaran Seçim yazımızda bu konuya da değinmiştik.
Neden ikinci katman şart?
Çünkü gerçek kullanıcı düzgün konuşmuyor ki! Biri “Acme’ye kesilecek fatura 10 saatlik çalışma için” derken, diğeri lafı geveleyerek “müşteriden alınacak ücret şu kadar” diye dolaştırır. Doğrudan söylemez. İşte burada model devreye girip boşlukları dolduruyor, noksan parçaları birleştiriyor. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Ama dürüst olayım: AI fallback kısmı ilk testlerde beklediğim kadar pürüzsüz değildi. En çok da eksik para birimi ya da garip sıralanmış kelimeler geldiğinde bazen düşük güven skoru dönüyordu — ki bu aslında normaldi, çünkü modelden mucize beklemek saçma olurdu. Beklenmedik bir şey değildi yani, ama yine de biraz şaşırttı.
İşte tam da bu noktada devreye giriyor.
{
"client": "Acme",
"hours": 10,
"rate": 100,
"currency": "GBP",
"confidence": "high"
}Kullanıcı Güveni İçin Küçük Ama Kritik Detaylar
Sistemin en çok hoşuma giden taraflarından biri güven alanını açıkça göstermesiydi. Yani çıktı geldikten sonra kullanıcıya sadece veri vermiyorsun; “bu veri ne kadar sağlam?” bilgisini de veriyorsun. Yeşil etiket yüksek güveni, sarı etiket ise AI destekli tahmini anlatıyor. Basit ama etkili. Bu konuyla ilgili Pixel Boyutunda Kandırmaca: SVG İçine Saklanan Hırsızlık yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
Araya gireyim: Bu detay ufak görünüyor, biliyorum. Ama UX açısından baya iş görüyor aslında. Çünkü kullanıcı formu körlemesine kabul etmiyor; gerektiğinde düzeltiyor, müdahale ediyor. Kurumsal tarafta bunu daha da önemseyen ekipler var mesela — finans departmanı olan yerlerde otomatik dolum güzel ama kontrol edilebilir olması şart. Net bir şekilde şart.
“AI ile otomasyon yapmak kolaydır; güven hissi vermek zordur.”
Bir de şu var: küçük startup ile enterprise arasındaki fark tam burada ortaya çıkıyor. Startup tarafında hız kazanımı yeterli olabiliyor. Kurumsalda ise izlenebilirlik, loglama ve onay adımı isteniyor — bu tartışmasız. Ha bu arada, benzer mantığı geçen ay İzmir’de çalışan bir danışmanlık ekibinde de gördüm; onlar otomatik dolumu sevdi ama her satır için manuel düzeltme alanının olmasını özellikle istedi (ki bu çoğu kişinin gözünden kaçıyor). Bilhassa vurguladılar bunu.
PDF Tarafı Sandığın Kadar Sıkıcı Değil
Garip gelecek ama, @react-pdf/renderer ile PDF üretmek dışarıdan bakınca kuru bir iş gibi duruyor. Ama hoş tarafları var aslında. React komponentleriyle sayfa düzeni kuruyorsun, sonra server-side render edip binary buffer olarak dönduruyorsun. Böylece tarayıcıda ayrıca şablon motoru kovalamıyorsun. Temiz bir akış.
Editör masasında bu konuyu not alırken aklıma hemen eski ajans günlerim geldi — 2019’da Levent’te müşteriye gidecek teklif PDF’lerini elle dizayn ettiğimiz dönemler. O süreç tam bir sabır testiydi, inan. Şimdi ise layout’u komponent olarak düşünmek işleri bayağı rahatlatıyor. Ciddi fark var.
Peki PDF’de neler vardı?
- Markalı başlık ve fatura numarası
- Müşteri bilgisi ve son ödeme tarihi
- Saat / ücret / tutar tablosu
- %20 KDV ya da VAT hesabı (bu kritik)
- Ödeme koşulları bölümü
Kulağa sıradan geliyor olabilir. Ve sıradan olmak burada aslında avantaj — faturanın amacı gösteri yapmak değil, okunmak ve doğrulanmak zorunda olmak. Şık tasarım güzel elbette, ama kağıt üstünde süper görünen bazı PDF’ler pratikte berbat olur; yazdırınca taşar, mobilde açılmaz, tabloyu yamultur. Benim beklentim genelde daha sade tarafta oluyor. Biraz karakter olsun isteriz, tamam, ama abartıya gerek yok.
Sorunlar Nerede Patlıyor?
Ters köşe gelelim şimdi. En çok sorun çıkaran yer genelde model kısmından önce geliyor: kullanıcının yazdığı ifade. İnsanlar kısa yazar. Yarım bırakır. Birimleri karıştırır, para sembolünü unutur… bunların hepsi normal, gerçekten normal. Ama sistem bunlara hazırlıklı değilse sonuç hemen bozuluyor. Anında.
Bak şimdi, Bir başka problem de maliyet. Her şeyi modele gönderirsen başlangıçta tatlı gelen ürün büyüdükçe pahalılaşır — bu kaçınılmaz. Bu yüzden regex-first yaklaşımı bence doğru seçim olmuş. Kağıt üstünde süper duran saf AI çözümü pratikte biraz hayal kırıklığı yaratabiliyor, dürüst olmak gerekirse.
Küçük startup için ne iyi çalışır?
Küçük ekiplerde ana hedef hız. Önce ürünü piyasaya çıkarırsın, sonra kullanım desenlerine bakarsın — başka türlü olmaz (en azından benim deneyimim böyle). Bu senaryoda düşük maliyetli ayrıştırma artı gerektiğinde model desteği gayet yeterli. Hatta tek geliştiriciyle yürüyen projelerde bakım yükü az olduğu için böyle hibrit mimari daha rahat nefes aldırır. Denedim, biliyorum.
Büyük ekipler neyi farklı yapar?
Kurumlarda iş değişir. Hata toleransı düşer, loglama artar, versiyonlama gerekir. Belki insan onayı eklersin, belki bölgesel vergi kuralları devreye girer, belki farklı para birimleri yüzünden ayrı doğrulama katmanı koyarsın. Yani aynı ürünün omurgası korunur ama çevresine ciddi kontrol mekanizmaları eklenir. Aynı motor, farklı kasa.
Bana Göre Asıl Ders Ne?
Lafı gevelemeden söyleyeyim: bu proje bana şunu gösterdi — yeniden kullanılabilir mühendislik sandığımızdan çok daha değerli. Bir kez düzgün pattern kurarsan ikinci ürünü sıfırdan başlamadan çıkarabiliyorsun. Resume AI Tailor’dan kalan PDF alışkanlığı burada yeniden işe yaradı; parsing stratejisi ise yeni probleme uyarlanabildi. Bunu geçen hafta Beşiktaş’taki ofiste not alırken fark ettim: iyi sistem kurmak bazen yeni özellik geliştirmekten daha büyük kaldıraç sağlıyor. Bazen çok daha büyük.
Evet. Konu aslında sadece fatura üretmek değildi (şaşırtıcı ama gerçek). Asıl mesele şu soruydu: “Bir hafta içinde bayağı farklı görünen ikinci ürünü çıkarabilir miyim?” Cevap net biçimde evetti — ama ancak disiplinli bileşenlerle. Mesela güven skoru olmayan bir akışta kullanıcı sürekli tereddüt ederdi. Ya da regex katmanı olmasa API maliyeti gereksiz şişerdi. Kısacası küçük kararlar toplamda büyük fark yaratıyor. Her seferinde.
Sıkça Sorulan Sorular
AI destekli fatura üreticisi gerçekten güvenilir mi?
Evet, doğru tasarlanırsa oldukça kullanışlı olur.
En çok da de de otomatik doldurma sonrası kullanıcıya düzeltme hakkı verirsen güven artar.
Tamamen kör otomasyondansa kontrollü akış daha sağlıklı çalışır.”
Neden doğrudan modeli kullanmak yerine regex eklendi?
Çünkü regex hızlı ve ucuzdur.
Basit girişlerin çoğunu API çağrısı olmadan çözer.
Modeli yalnızca zor durumlarda kullanmak maliyeti ciddi biçimde azaltır.”
Küçük işletmeler için böyle bir araç mantıklı mı?
Bence evet.
Saatlik çalışan ajanslar, freelancer’lar ve danışmanlık ekipleri için bayağı işe yarar.
Tekrar eden faturaları hızlandırdığı için zaman kazandırır.”
PDF üretimi neden önemli görülüyor?
Müşteriye giden çıktı profesyonel görünmek zorunda olduğu için önemli.
PDF hâlâ evrensel format gibi davranıyor;
her yerde açılıyor,
kolay paylaşılıyor.”
Kaynaklar ve İleri Okuma
@react-pdf/renderer Resmi Dokümantasyonu
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
