Restoran ve Kafe Yazılımı: Kendi Ürünümüzü Geliştirirken Öğrendiklerimiz

Bir restoranın akşamı hızlı akar ve affetmez. Saat yedi buçukta salon dolar; garson aynı anda üç masaya bakar, mutfak yetişmeye çalışır, paket sipariş telefonu meşgul eder, kasada hesap bekleyen bir çift vardır. Bu tempoda yazılımın yavaşlaması, donması ya da iki ekranın birbirinden habersiz kalması demek, somut olarak soğuyan tabak, unutulan sipariş ve kapıda bekleyen kurye demektir. Muhasebe yazılımı bir raporu beş saniye geç üretirse kimse fark etmez; adisyon ekranı beş saniye geç açılırsa bütün salon fark eder.

İşin ikinci zorluğu, bu temponun tek bir kişide değil, birbirinden farklı rollerde yaşanmasıdır. Garson masada, aşçı ocakta, kasiyer kasada, kurye yolda, patron çoğu zaman başka şehirdedir. Hepsinin aynı anda aynı gerçeği görmesi gerekir: hangi masa dolu, hangi sipariş mutfakta, hangi hesap açık. Sektörde yaygın manzara ise bunun tersidir — bir POS programı, ondan bağımsız bir QR menü, üçüncü bir yerden alınmış paket servis uygulaması ve kâğıt üstünde tutulan stok. Birbiriyle konuşmayan bu parçaların arasındaki boşluğu, her gün yeniden, insan emeği doldurur.

Biz bu yazıyı bir gözlemci olarak değil, bu problemin içinden geçen bir ekip olarak yazıyoruz. Horeca'yı — kafe, restoran ve benzeri mekânlar için çok kiracılı bir işletim platformunu — sıfırdan geliştirdik ve geliştirmeye devam ediyoruz. Aşağıda hem sektörün yazılım ihtiyacını bir çerçeveye oturtacağız hem de bu çerçevenin her parçasını kendi ürünümüzde nasıl gerçeklediğimizi, nerede zorlandığımızı ve neyi bilinçli olarak sonraya bıraktığımızı adım adım anlatacağız.

"Restoran yazılımı" tek bir ürün değil, bir aile. En görünür üyesi satış noktası, yani POS ve adisyon: siparişin alındığı, hesabın tutulduğu, ödemenin kaydedildiği katman. Onun hemen yanında dijital menü durur — masadaki QR koddan açılan, fiyatı ve içeriği her an güncellenebilen menü. Mutfak tarafında KDS (mutfak ekranı) vardır: fişlerin kâğıt yerine ekrana düştüğü, hangi siparişin ne kadardır beklediğinin görüldüğü ekran. Arka planda stok ve reçete katmanı çalışır: hangi üründe hangi malzemeden ne kadar kullanıldığı, maliyetin ve kâr marjının gerçekte ne olduğu. En üstte de raporlama oturur: günün, haftanın, şubenin fotoğrafı.

Bir de işin misafir tarafı var; sektör buna genellikle 'engagement' diyor. Rezervasyon, garson çağırma, masada ödeme, sadakat programı, hediye kartı, kampanya... Bunlar POS'un çekirdeğine göre daha az hayati görünür ama işletmeyi rakiplerinden ayıran çoğu zaman bu katmandır: misafirin telefonuyla kurduğu ilişki.

Piyasadaki tipik yol, bu ailenin her üyesini ayrı bir tedarikçiden almaktır. Bunun kısa vadede bir mantığı da vardır: her parça kendi işinde iyidir. Uzun vadedeki bedeli ise entegrasyonun sizin sorununuz hâline gelmesidir. QR menüden gelen sipariş POS'a elle geçilir; stok programı satıştan haberdar olmaz; sadakat uygulaması adisyonu görmez. Biz Horeca'yı tam olarak bu bedeli ortadan kaldırmak için tek çekirdek üzerine kurduk: bütün bu katmanlar aynı veritabanının, aynı iş kurallarının ve aynı gerçek zamanlı akışın üstünde yaşar.

Bir mekânın işleyişini yazılıma çevirirken verdiğimiz ilk karar şuydu: ekranlar ayrı programlar değil, aynı akışın adımları olmalı. Masayı açan garson, ocaktaki aşçı, kasadaki adisyon ve yoldaki kurye aynı anı yaşar; yazılım da bunu böyle modellemelidir. Horeca'da bir sipariş tek bir yaşam döngüsünden geçer: beklemede başlar, onaylanır ya da reddedilir, mutfağa düşer, hazırlanır, teslim edilir ve ödemeyle kapanır. Bu zincirin her halkası ayrı bir rolün ekranında görünür ama zincir tektir — biz bu akışı uçtan uca, gerçek cihazlarla test ederek doğruladık.

Bu kararın doğal sonucu, rol başına ayrı uygulama oldu. İşletme paneline Desk diyoruz: menü, salon planı, stok, personel, raporlar — patronun ve müdürün masası. Garsonun elindeki uygulama Floor: masalar, siparişler, servis çağrıları, vardiyası. Mutfaktaki ekran Flame: kâğıtsız fiş akışı. Kasadaki Till: tahsilat ve adisyon kapanışı. Vitrindeki televizyonları Beam yönetir; paket servisin kuryesi Route ile çalışır. Hepsinin arkasında tek bir API ve tek bir gerçek durur.

Gerçek zamanlılık burada süs değil, zorunluluk. Garson siparişi gönderdiği saniye mutfak ekranında görmeli; mutfak 'hazır' dediği anda garsonun telefonu titremeli. Bunu WebSocket tabanlı canlı bağlantı ve mobil push bildirimlerinin birlikteliğiyle çözdük. Salonun yoğun saatinde ekranlar arasında 'yenile' tuşuna basan kimse olmamalı — akış kendi kendine akmalı.

Sektörün kalbi adisyondur ve adisyon göründüğünden çok daha karmaşık bir nesnedir. Masaya dört kişi oturur; ikisi ortak öder, biri kendi kalemlerini ayırır, biri kartla öder. Araya bir ikram girer, bir kalem iade olur, hesabın yarısına iskonto uygulanır. Servis biterken bahşiş bırakılır ve o bahşişin vardiyadaki ekibe âdil dağıtılması gerekir. Bunların hepsi aynı adisyonun içinde, birbiriyle tutarlı biçimde yaşamak zorundadır.

Horeca'da bu yüzden ödeme, adisyonun tamamına değil tek tek kalemlerine bağlanır: kimin neyi ödediği kayıt düzeyinde bellidir. Hesap bölme, ikram ve iskonto ayrı düzeltmeler değil, adisyonun doğal hareketleridir. Bahşiş kendi modelini taşır ve dağıtım kuralıyla birlikte kaydedilir. Para söz konusu olduğunda 'yaklaşık doğru' diye bir şey yoktur; bu nedenle ödeme tarafındaki kritik kayıtları, araya çökme girse bile tutarlılığı koruyan bir işlem kuyruğu deseniyle (transactional outbox) yazıyoruz. Gün sonunda kasadaki rakamla sistemdeki rakam birbirine 'yakın' değil, eşit olmalıdır.

Masada ödeme de aynı anatominin parçası: misafir, garsonu beklemeden telefonundan kendi kalemlerini seçip hesabını kapatabilir. Bu, kalem bazlı ödeme modelinin doğrudan bir armağanıdır — mimariyi baştan doğru kurunca üst katmandaki özellikler zorlamadan gelir.

Menü, dışarıdan bakınca bir liste gibi görünür; içeriden bakınca bir veri modelidir. Kategoriler, ürünler, ürün varyantları (küçük/orta/büyük), opsiyon grupları (ekstra peynir, az şekerli, sos seçimi)... Horeca'da menü bu yapıyla modellenir ve tek yerden yönetilir: Desk'te yapılan bir fiyat değişikliği, masadaki QR menüye, garsonun Floor ekranına ve kasadaki Till'e aynı anda yansır. Mevcut menüsü zaten hazır olan işletmeler için toplu menü aktarımı da ayrı bir başlık olarak çözüldü — kimse yüz elli ürünü tek tek elle girmek zorunda kalmamalı.

Menünün altında sektörün en çok ihmal edilen katmanı yatar: reçete. Her ürünün arkasında bir malzeme listesi durur — hangi malzemeden ne kadar. Reçete tanımlıysa üç şey kendiliğinden olur: satış olduğunda malzeme stoğu düşer, ürünün gerçek maliyeti hesaplanır ve 'bu ürün gerçekten kazandırıyor mu?' sorusunun cevabı tahmin olmaktan çıkar. Horeca'da stok kalemleri, stok hareketleri ve reçete satırları bu zinciri kurar; maliyet raporu da üstüne oturur.

Bu katmanı ürünün merkezine koymamızın nedeni basit: yeme-içme sektöründe ciro çok, kâr azdır. Bir işletme cirosunu zaten kasasından bilir; bilmediği şey, o cironun içinde hangi ürünün marjı taşıdığı, hangisinin sessizce zarar yazdırdığıdır. Yazılımın işi tam burada başlar.

Birincisi eşzamanlılık. Yoğun saatte aynı masaya iki garson aynı anda kalem ekleyebilir, mutfak bir yandan durumu güncellerken kasa hesabı bölmeye başlayabilir. Bu çakışmaların hiçbiri kullanıcıya 'hata' olarak dönmemeli, veri de asla tutarsız kalmamalı. Sipariş yaşam döngüsünü katı durum geçişleriyle tanımlamamızın ve para tarafında işlem kuyruğu kullanmamızın nedeni bu.

İkincisi personel devri. Bu sektörde ekipler sık değişir; yazılımın eğitimi bir öğleden sonradan uzun sürüyorsa yazılım yanlış tasarlanmış demektir. Rol başına ayrı uygulama kararının bir nedeni de bu: garson yalnızca garsonun ekranını görür, kasiyer yalnızca kasanın. Kimse kullanmayacağı kırk menünün arasında kaybolmaz.

Üçüncüsü çok kiracılılık. Aynı sistemin üstünde birbirinden habersiz yüzlerce işletme yaşayacaksa, veri izolasyonu bir özellik değil varoluş şartıdır. Horeca'da her iş kaydı organizasyona bağlıdır ve kiracı hiyerarşisi gerçek dünyayı izler: organizasyon, altında markalar, markaların altında şubeler. Tek kafeli işletme de bu modelin içinde rahat eder, çok markalı bir grup da.

Dördüncüsü cihaz gerçekliği. Sahada karşınıza her marka tablet, telefon ve televizyon çıkar. Operasyon uygulamalarını Flutter ile yazmamızın nedeni bu çeşitlilik: aynı kod tabanı garsonun Android telefonunda da, mutfaktaki tablette de, vitrindeki TV'de de çalışır. Panelleri ise web'de (Angular) tuttuk — patronun raporu her yerden açabilmesi gerekir.

Bu noktada dürüst bir fotoğraf çekelim. Horeca'nın çekirdeği bugün ayakta: .NET 9 üzerinde tek bir API, PostgreSQL üzerinde altmışın üzerinde iş tablosu, sekiz istemci ucuna hizmet veren yüze yakın controller. QR menüden siparişe, mutfaktan ödemeye ve adisyon kapanışına uzanan ana akış gerçek cihazlarla uçtan uca test edildi. İki yönetim paneli — işletmeler için Desk, platform operatörü için Orbit — dolgun durumda; Floor sahada en olgun mobil uygulamamız, Flame, Till, Beam ve Route onu takip ediyor.

Çekirdeğin çevresinde geniş bir modül halkası var ve bu halka aktif olarak büyüyor: rezervasyon, catering, garson çağırma, vale, sadakat programı, hediye kartı, askıda ürün, kampanya, doğum günü, WiFi karşılama portalı, müzik isteği, masalar arası ikram, sosyal duvar... Bunların her biri kendi veri modeli ve ekranıyla sistemde duruyor. Yalnızca son üç haftada teslimat, catering, sadakat, hediye kartı ve maliyet muhasebesi dahil onlarca tarihli veritabanı migrasyonu işlendi — 'bitmiş ürün' demiyoruz; 'üretime hazır çekirdek, üstünde genişleyen bir ekosistem' diyoruz.

Aynı dürüstlükle, henüz olmayanları da söyleyelim: harici ödeme kuruluşu entegrasyonu, e-fatura ve fiş yazıcısı bağlantıları bugün kodda yok; yol haritasında duruyorlar. Bir tanıtım yazısında bunları 'var' gibi göstermek kolay olurdu — ama biz sattığımız her cümlenin kodda karşılığını gösterebilmeyi tercih ediyoruz.

Bir mahalle kahvecisiyle çok katlı bir otel restoranı aynı yazılımı kullanamaz — daha doğrusu kullanmamalı. Kahvecinin vale modülüne, otelin askıda kahve modülüne ihtiyacı yok. Ama ikisinin çekirdeği aynıdır: menü, sipariş, ödeme, stok. Bu gerilimi çözmek için Horeca'yı yetenek-güdümlü (capability-driven) kurduk: sistemde bir modül kataloğu yaşar, her modülün mekân tipine göre önerilen bir karşılığı vardır ve işletme hangi modülleri kullanacağını şube bazında açıp kapatır.

Pratikte bu şöyle görünür: sisteme bir dönerci, bir kokteyl barı ya da bir otel kahvaltı salonu eklerken on iki mekân tipinden birini seçersiniz; matris size o tip için anlamlı modül setini önerir, siz de ihtiyaca göre inceltirsiniz. Çalışma zamanında hiçbir kod 'bu mekân dönerci mi?' diye sormaz; yalnızca hangi yeteneklerin açık olduğunu bilir. Yeni bir mekân tipi eklemek bu yüzden çekirdeğe dokunmayı gerektirmez.

Modüllerin üstünde abonelik katmanı durur: işletme aboneliği ve faturaları platform tarafında yönetilir. İlginç bir simetri olarak, aynı altyapı işletmelerin kendi müşterilerine abonelik satmasına da izin verir — mahalle kahvecisinin aylık kahve aboneliği gibi. Çok kiracılı bir platform kurarken verdiğiniz mimari kararlar, bazen kiracılarınızın kendi iş modellerine de sirayet eder; bu, işin en keyifli yan etkilerinden biri.

Şimdiye kadar hep işletmenin içinden baktık; bir de masadan bakalım. Misafir oturur, telefonuyla masadaki kodu okutur ve menü açılır — uygulama indirmeden, üyelik olmadan. Sipariş verir; sipariş doğrudan mutfağın akışına düşer. Bir şeye ihtiyacı olduğunda ekrandan garson çağırır; bu çağrı Floor'daki doğru garsona gider. Kalkarken isterse garsonu bekler, isterse kendi kalemlerini seçip telefonundan öder.

Bu temel akışın üstüne, mekânın karakterine göre açılan bir deneyim katmanı gelir: doğum günü sürprizleri, çaldığı müziğe söz hakkı tanıyan müzik isteği, başka bir masaya ikram gönderme, askıda kahve, sosyal duvar, WiFi karşılama sayfası... Bunlar POS satan firmaların gündemine genellikle hiç girmeyen modüllerdir; bizim gündemimize girmelerinin nedeni, mekân dediğimiz şeyin bir kasadan değil, bir sosyal deneyimden ibaret olması. Sadakat programı, hediye kartı ve kampanyalar da aynı katmanın kalıcı ilişki kuran parçaları.

Teknik açıdan kritik nokta şu: misafir tarafının tamamı, işletme tarafıyla aynı çekirdeği kullanır. QR menüdeki ürün, Desk'te tanımlanan üründür; masada ödenen hesap, Till'in gördüğü adisyondur. Misafir deneyimi ayrı bir ürün değil, aynı akışın öbür ucudur.

Modern bir yeme-içme işletmesinin siparişi artık yalnızca masadan gelmiyor. Aynı mutfak, salondaki adisyonu, gel-al siparişini ve paket servisi aynı anda besliyor. Bunu modellemek için siparişin 'nasıl teslim edileceğini' ayrı bir kavram olarak tuttuk: aynı sipariş nesnesi, masa servisi, gel-al ya da kurye teslimatı olarak akabilir. Mutfak açısından hiçbir şey değişmez — fiş aynı ekrana düşer; değişen yalnızca siparişin salondan mı, kapıdan mı çıkacağıdır.

Kurye tarafı için ayrı bir uygulama var: Route. Kurye kendi teslimatlarını, adreslerini ve kazançlarını telefonundan görür; işletme ise hangi paketin yolda, hangisinin teslim edilmiş olduğunu adisyonla aynı sistemin içinden izler. Üçüncü taraf yemek platformlarına komisyon ödeyen işletmeler için bu, kendi teslimat kanalını kendi yazılımıyla işletebilmek demek — siparişin, müşterinin ve verinin işletmede kalması demek.

Masa dışı akışın iki üyesi daha var. Rezervasyon, salon planının üstünde yaşar: hangi masa, hangi saat, kaç kişi. Catering ise kendi başına küçük bir sipariş dünyasıdır — kalemleri, teslim tarihi ve tutarıyla ayrı bir modelde tutulur; yüz kişilik bir organizasyon siparişini akşam servisinin adisyon akışına sıkıştırmaya çalışmak, iki akışı da bozar. Bu ayrımları baştan yapmak, her akışın kendi doğasında kalmasını sağlıyor.

Servis biter, salon boşalır ve geriye bir soru kalır: bugün gerçekte ne oldu? Reçeteli maliyet, kalem bazlı ödeme ve tek akış üzerine kurulmuş bir sistemde bu sorunun cevabı toplama-çıkarma değil, doğal bir çıktıdır. Desk'teki gösterge paneli günün cirosunu, sipariş dağılımını ve açık adisyonları anlık gösterir; platform operatörü kendi Orbit panelinden bütün kiracıların sağlığını izler. Rakamlar kasadan değil, akışın kendisinden gelir — bu yüzden gün sonunda 'kasayla sistem tutmuyor' toplantısı yapılmaz.

Raporlamanın bir adım ötesi tahmin. Geçmiş satış verisi birikince sistem, haftanın günlerine ve saatlere göre yoğunluk ısı haritası çıkarabilir ve önümüzdeki günler için talep tahmini üretebilir. Bu, 'salı akşamına kaç kişi çağırayım, ne kadar malzeme alayım' sorusunun sezgiden veriye taşınmasıdır. Personel performans raporu da aynı verinin başka bir kesiti: kim kaç masaya baktı, hangi vardiya nasıl geçti — bahşiş dağıtımıyla birlikte, âdil bir tablo.

Çok şubeli işletmelerde raporlamanın asıl değeri merkezîlikte ortaya çıkar. Organizasyon-marka-şube hiyerarşisi sayesinde patron tek ekrandan bütün şubeleri karşılaştırır: hangi şube hangi üründe güçlü, hangisinin maliyeti sapmış. İkinci şubeyi açmak yazılım tarafında yeni bir kurulum değil, aynı organizasyonun altına yeni bir satırdır — raporlar da o satırı otomatik kapsar.

Birinci adım keşif ve kurulum tasarımı: işletmenin akışını dinleriz — kaç salon, kaç masa, paket servis var mı, mutfak nasıl bölünmüş? Mekân tipi seçilir, modül seti buna göre daraltılır. İkinci adım menü ve salon kurulumu: kategoriler, ürünler, varyantlar, reçeteler ve salon planı sisteme işlenir; mevcut bir menü varsa toplu aktarımla taşınır.

Üçüncü adım roller ve cihazlar: ekip üyeleri tanımlanır, garsonlara Floor, mutfağa Flame, kasaya Till, vitrine Beam kurulur; masalara QR kodlar yerleştirilir. Dördüncü adım ekip eğitimi — ki rol başına tek ekran ilkesi sayesinde bu genellikle işin en kısa adımıdır: herkes yalnızca kendi ekranını öğrenir.

Beşinci adım canlıya geçiş ve izleme: ilk servisler yakından izlenir, akıştaki sürtünmeler yerinde giderilir, raporların doğru aktığı teyit edilir. Bundan sonrası artık işletme ile platform arasında yaşayan bir ilişkidir: yeni modüller ihtiyaç oldukça açılır, mevsim menüsü geldiğinde menü güncellenir, ikinci şube açıldığında aynı organizasyonun altına yeni şube eklenir. Yazılım kurulup gidilen bir şey değil, işletmeyle birlikte yaşayan bir şeydir — zaten SaaS modelinin asıl vaadi de budur.

Bu yazıyı bir alışveriş rehberine çevirmeden, kendi geliştirme sürecimizde önemli olduğunu bizzat gördüğümüz soruları bırakalım. Bir: QR menü, POS, mutfak ve stok aynı çekirdekte mi yaşıyor, yoksa entegrasyon sizin sorununuz mu? İki: ödeme kalem bazında mı tutuluyor — hesap bölme ve masada ödeme buna bağlıdır. Üç: reçete ve maliyet takibi var mı, yoksa 'stok modülü' yalnızca sayım defteri mi?

Dört: garsonun ve mutfağın ekranı gerçek zamanlı mı güncelleniyor, yoksa birileri 'yenile'ye mi basıyor? Beş: yazılımı yeni bir çalışana öğretmek ne kadar sürüyor? Altı: iki şube açıldığında model buna hazır mı — yoksa ikinci bir kurulum mu gerekiyor? Yedi: kullanmadığınız özellikler için de mi ödüyorsunuz, yoksa modüler bir yapı mı var?

Bu yedi sorunun hiçbiri pazarlama sorusu değil; hepsi mimari sorusudur. Cevapları da broşürde değil, ürünün veri modelinde saklıdır. Biz Horeca'yı bu sorulara 'evet' diyebilecek şekilde kurduk — ve nerede henüz 'evet' diyemiyorsak, bunu yukarıda açıkça yazdık.

Yeme-içme işletmesi yazılımı, sektörlerin en acımasız test ortamlarından biridir: akşam servisi ne mimari borcunuzu affeder ne de eksik düşünülmüş bir akışı. Horeca'yı geliştirirken en net öğrendiğimiz şey şu oldu: bu sektörde iyi yazılım, çok özellikli yazılım değil, tek akışlı yazılımdır. Masayı açan elin, ocağı yakan elin ve hesabı kapatan elin aynı gerçeği görmesi — geri kalan her şey bunun üstüne inşa edilir.

Kendi işletmeniz için bir sistem arıyorsanız ya da sektöre özel bir yazılım fikrini konuşmak istiyorsanız, kapımız açık: ilk görüşme bağlayıcı değildir ve karşınızda satış ekibi değil, bu ürünü bizzat yazan ekip olur.