Hesap tablosundan çıkan teklif motoru

Problem

Üretici, cam balkon ve giyotin sistemlerini kendi bayi ağı üzerinden satıyor. Bayi müşterinin evinde ölçü alır, sistemi, rengi ve cam tipini seçer, fiyatı söyler. Bu fiyat bir hesap tablosundan çıkıyordu.

Hesap tablosunun asıl sorunu yavaş olması değildi. Sorun şuydu: her bayide onun bir kopyası vardı. Fiyat listesi değiştiğinde kimin hangi sürümü kullandığı bilinmiyordu, formüldeki bir hata sessizce yayılıyordu ve verilmiş bir teklifin hangi kurla hesaplandığı üç ay sonra kimsenin elinde değildi.

Bu ürünün kalbi bir ekran değil, hesaplama motoru. Arayüz yanlışsa düzeltilir; fiyat yanlışsa müşteriye çoktan gitmiştir.

Yaklaşım

Motoru sunucuya, tek yere koyduk. Mobil uygulama da web paneli de aynı hesaplama ucunu çağırır. Motor iki yerde yazılsaydı iki farklı teklif tutarı çıkardı; bu fark ancak müşteri iki teklifi yan yana koyduğunda görülür. Aynı gerekçeyle bölme dağıtımı da sunucuda hesaplanır: önyüz gelen koordinatları çizer, kendi geometrisini kurmaz.

Parasal değerleri API üzerinde metin olarak taşıdık. Kayan nokta aritmetiği bir teklif tutarında kabul edilebilir bir hata payı değildir. Önyüz aritmetik yapmaz, yalnızca biçimlendirir.

Görmeye yetkisi olmayan alanı yanıta hiç koymadık. Maliyet görme izni olmayan bir bayi kullanıcısının yanıtında maliyet ve kâr alanları boş gelmez — bulunmaz. Ekranda gizlemek bir arayüz tercihidir; güvenlik, alanın gönderilmemesidir.

Her teklife kendi kur anlık görüntüsünü bağladık. Aksi hâlde aynı teklif üç ay sonra açıldığında başka bir tutar gösterirdi; bu da tarafların hangisinin haklı olduğunun anlaşılamadığı bir tartışmadır.

Ne inşa edildi

Sistem bugün şunları yapıyor:

• Teklif üretir. Bayi sistem, renk, cam ve ölçüleri girer; sunucu maliyeti ve satış fiyatını hesaplar, teklifi çıkarır.
• Bölme dağıtımını hesaplar ve çizdirir. Sunucu koordinat listesi döner, arayüz onu çizer.
• Kur anlık görüntüsü tutar. Bir teklif aylar sonra açıldığında aynı tutarı gösterir.
• Kiracıları ayırır. Bayilerin verisi veri katmanında birbirinden ayrılır; bir geliştiricinin filtre yazmayı unutması başka bir bayinin verisini açığa çıkarmaz.
• Rol ve izne göre yanıt üretir. Beş rol ve yirmi üç izinden oluşan matris, kullanıcının göremeyeceği alanları yanıttan tamamen çıkarır.
• İşi hattan geçirir. Teklif sonrası iş üretim, montaj ve teslim aşamalarında izlenir.

Nasıl doğrulandı

Motor geliştirilirken üreticinin kendi hesap tablosu referans alındı ve çıktı basamak basamak karşılaştırıldı: sonuçlar on ondalık basamağa kadar örtüşüyor.

Karşılaştırmanın beklenmedik bir yan ürünü oldu: üreticinin tablosunda dört hata bulundu ve raporlandı. Motorun doğruluğunu gösteren en güçlü kanıt bu — çünkü referansın kendisindeki sapmayı yakalayacak kadar hassas çıktı.

API bugün 53 uç yayınlıyor ve 88 birim ile 195 uçtan uca testin tamamı geçiyor. Her değişiklik PR ve tek onay disipliniyle geçer, her istek makine tarafından denetlenir.

Mobil demo 30 Temmuz 2026’da teslim edildi.

Aynı ürün bu sırada ikinci bir üreticiye, kendi markası ve kendi sistem kümesiyle yeniden kuruldu. Asıl sınav oydu: bir kez yazılmış bir iş uygulamasının, ikinci müşteride sıfırdan yazılmadan ayağa kalkıp kalkamayacağı.

Teknoloji

NestJS · TypeScript · Prisma · PostgreSQL · Next.js · Flutter · Docker