TabelaI

Zirve Asansör — Asansör Bakım Platformu

Babam Trabzon'da asansör bakım şirketi işletiyor.

Altı proje

I2026

Backend — MySQL Üstünde Tek REST Sözleşmesi

Baştan ORM kullanmamaya karar verdim. Oracle SQL eğitimim vardı, bir sorguyu bir model katmanından daha hızlı okuyordum ve şemanın çok değişeceği belliydi. Değişti de: boş veritabanından sırayla uygulanan 28 numaralı migration dosyası ve on üç revizyon geçiren bir API sözleşmesi. Node ve Express, MySQL üstünde; hazır ifadelerle ham SQL, üç rol için tek JWT düzeni. Para bir DECIMAL sütunu, kodda tamsayı kuruş; yuvarlama hiçbir bakiyeye dokunmuyor. Aylık aidatı üreten cron bugünün tarihini sormuyor. Bu ayın aidatı üretildi mi diye soruyor; sunucu ayın birinde kapalıysa, açıldığında üretiyor.

Node.jsExpressMySQL

II2026

Yönetim Paneli — Patronun Masaüstü Paneli

2026'da tek kullanıcı için masaüstü uygulaması yazmak tuhaf bir tercihti ve bunu bilerek yaptım. Java biliyorum, sistemde JavaScript olmayan bir istemci olsun istiyordum ve masaüstü istemci sunucuyla sessizce kod paylaşamıyor; bu yüzden REST API'nin ilk günden eksiksiz olması gerekti. Bu o uygulama: JavaFX, panelden araç listesine dokuz bölüm, backend'e Java'nın HttpClient'ıyla bağlanıyor. Tahsilat, kaydedilmeden önce hangi ayları kapatacağını gösteriyor, sonra firmanın kâğıt makbuzunu antetiyle ve imzasıyla kopyalayan bir makbuz basıyor. Sözleşmeler ve finans raporları da aynı yoldan gidiyor: WebView'da önizleme, sonra PDF.

Java 21JavaFXMaven

III2026

Yönetim PWA — Patronun Paneli, iPad'de

Masaüstü paneli ofisteki tek bir Mac'te duruyor ve babam onu yanında taşıdığı iPad'de istiyordu. Yeniden yazmak söz konusu değildi, bu yüzden bu bir kopya. Her ekran JavaFX'teki sınıfından aktarıldı: aynı metin, aynı uç noktalar, aynı sayfalama. Masaüstünde bir hata varsa kopya o hatayı da yapıyor ve dokümandaki bir tablo bunu benim karar vermem için kaydediyor. Beş gün, 26 commit. Bir bağlantıdan PWA olarak kuruluyor, mağaza gerekmiyor.

ReactTypeScriptVite

IV2026

Müşteri PWA — Apartman Yöneticisinin Uygulaması

İlk sürüm her apartman yöneticisine bina koduyla ve WhatsApp'tan göndereceğimiz bir şifreyle giriş yaptırıyordu. Yapılacak standart şeydi ve hiç işlemeyecekti. Çoğu yaşlı, bir kısmı her yıl değişen yaklaşık 300 yönetici; her birine telefona yazılacak bir şifre, hem de belki istemeyen biri tarafından. Giriş yöneticinin telefon numarasına döndü, firmanın zaten elinde olan numaraya; şifre isterseniz sonradan ekleyebileceğiniz bir şey oldu. Uygulamanın kendisi binanın borcunu ay ay gösteriyor, alınan ve iptal edilen ödemeleri, son bakım ziyaretini ve yanında acil numarayla arıza bildirme düğmesini. Bir bağlantıdan ya da kareokuttan kuruluyor, iPhone'lara App Store'a girmeden ulaşıyor.

ReactTypeScriptVite

V2026

Teknisyen — Çevrimdışı Çalışan Saha Uygulaması

Makine dairelerinde ve bodrumlarda sinyal yok ve teknisyen bir ziyareti kaydetmek istediğinde tam orada duruyor. Bu yüzden uygulama önce telefona yazıyor. Ekran hemen kaydedildi diyor, kayıt bir kuyruğa giriyor, kuyruk bağlantı gelince senkronize oluyor. Her kayıt telefonda üretilmiş bir kimlik taşıyor; bağlantı koptuktan sonra yeniden göndermek ikinci bir kayıt açmak yerine aynı ziyareti güncelliyor. Bunun etrafında ilçeye göre bina listesi, henüz kimsenin üstlenmediği açık arızalar ve firmanın hep kullandığı kâğıt formun aynısı olan, müşteriye verilebilecek bir PDF olarak çıkan servis formu var.

React NativeExpoTypeScript

VI2026

Beşikdüzü Asansör — Tanıtım Sitesi

Sitenin ilk planında asansör kabini siz kaydırdıkça sayfada aşağı iniyordu. Yeniden tasarım bunu tersine çevirdi. Sayfayla birlikte hareket eden kabin, yanınızdan geçen herhangi bir şeyden farksız. Yayındaki sürüm tam tersini yapıyor: kabin sağdaki kuyuda sabit duruyor ve katlar onun yanından geçiyor, cam bir asansörün içinden göründüğü gibi. Başlıktaki nokta matris gösterge hangi katta olduğunuzu söylüyor, sağdaki düğme paneli sizi bölümler arasında gezdiriyor. Sayfa hiç API çağırmıyor, hiçbir şey saklamıyor ve düz HTML olarak önceden basılıyor; herhangi bir betik gelmeden çiziliyor. Platformun gerçekten yayında olan tek parçası.

ReactViteSSR

Sorun

Şirketin hiç yazılımı yoktu. Aidatlar bir deftere yazılıyor, ödemeler nakit olarak babama veriliyor, hangi binanın hangi aylar için borçlu olduğu onun kafasında duruyordu. Bir yönetici bakiyeye itiraz ettiğinde gösterecek bir şey yoktu.

Apartman yöneticileri çoğunlukla yaşlı, teknolojiyle arası iyi olmayan ve bir iki yılda bir değişen insanlar. Onlar için yapılacak her şeyin merdiven boşluğunda telefon tutan birine göre olması gerekiyordu. Teknisyenler de günlerini sinyalin olmadığı makine dairelerinde ve bodrumlarda geçiriyor; bu, ziyareti kaydetmek için bağlantı isteyen bir uygulamayı baştan eledi.

Mimari

Her şeyin sahibi MySQL üstünde tek bir Node ve Express backend'i. Veritabanına dokunan tek şey o, API sözleşmesini değiştirmeye yetkili tek yer de o. Her istemci ayrı bir depo; sözleşmenin bir kopyasına karşı yazılıyor ve onu düzenleyemiyor.

Masaüstü paneli JavaFX. Bunu biraz Java bildiğim için seçtim, biraz da masaüstü istemci hile yapamadığı için: API'nin ilk günden eksiksiz olmasını zorluyor. iPad paneli masaüstünün ekran ekran web kopyası. Müşteri uygulaması bir bağlantıdan ya da kareokuttan kurulan bir PWA; çünkü yerel bir iOS uygulaması App Store dışında dağıtılamıyor ve bu kullanıcılar zaten mağazada bir şey aramayacaktı. Teknisyen uygulaması React Native, çünkü çevrimdışı depolama ve ileride push gerekiyor.

Bunların altında her kayıt bir binaya ait, kişiye değil; yönetici değişir, borç kalır. Bakiye hiç saklanmıyor. Geçerli aidatların toplamından geçerli ödemelerin toplamı çıkarılıyor, her sorulduğunda yeniden. Mali hiçbir kayıt silinmiyor; yanlış ödeme gerekçesiyle iptal ediliyor ve görünmeye devam ediyor. İzin verdiğim tek istisna tamirat borcu kalemi, o doğrudan kaldırılabiliyor.

Benim rolüm

Tek kişilik bir projeydi ve kararlar bendeydi: mimari, veri modeli, API sözleşmesi ve her ekranın nasıl davranacağı. Uygulamayı yapay zekâ kodlama ajanlarıyla, önce dokümantasyon diyerek yürüttüm. Bir mimari doküman var, bir de sözleşme. Her istemci oturumu bu dosyalara yönlendirildi ve onları değiştiremeyeceği söylendi; sözleşmenin değişmesi gerektiğinde backend değiştirdi, kopyalar yenilendi.

Daha önce yapmadığım kısımları, çevrimdışı senkron kuyruğunu, push'u, Caddy ile Docker'ı, JWT ayrıntılarını baştan yönettiğim değil öğrendiğim alanlar olarak listeledim ve onları diğerlerinden daha dikkatli okudum. Kendime koyduğum kural: açıklayamadığım dosya commit'lenmez.

Ölçek

Altı depo, 12 Haziran ile 16 Eylül 2026 arasında 168 commit. Backend 28 SQL migration'ı, 15 tablo ve 58 uç nokta; on dört test paketi var, veritabanına dokunanlar gerçek veritabanında çalışmayı reddediyor. Sözleşme bu süreçte on üç revizyon geçirdi, her biri tarihi ve gerekçesiyle kayıtlı. İşin kendisi iki şehirde yaklaşık 300 bina, dört teknisyen ve parayı toplayan bir kişi.

Ne öğrendim

Yaptığım üç şey yanlıştı ve değiştirilmek zorunda kaldı; bana çalışan kısımlardan daha çok şey öğrettiler.

Ödemelerin ilk sürümü bakım aidatını ve tamirat borcunu tek havuza koyuyor, hangisi eskiyse onu kapatıyordu. Test edildi, doğruydu, pratikte babamın kafasını karıştırdı: tamirat için verilen para eski bir bakım ayına gidebiliyordu. Bir gün dayandı. Sonra ödemelere tip geldi, iki borç ayrı defterlere ayrıldı.

Müşteri girişi bina kodu artı zorunlu şifreyle başladı; şifre WhatsApp'tan gönderiliyordu. Çoğu yaşlı ve teknolojiyle arası iyi olmayan yaklaşık 300 yönetici bu şekilde sisteme alınamayacaktı. Giriş yöneticinin telefon numarasına döndü. Şifre, isteyenin eklediği bir şey oldu.

Teknisyen ana ekranı önce günler üzerine kuruldu: bir tarih şeridi, bir güne dokun, o günün işini gör. Teknisyenler güne göre çalışmıyor. İlçeye göre çalışıyorlar. O ekran iki gün dayandı.