Projeler ve Bütçeler İçin Bir İnşaat Web Uygulaması Nasıl Oluşturulur

Bir Şantiyedeki Gerçek İş Akışıyla Başlayın

Ekranları tasarlamadan veya araç seçmeden önce işin ofisle saha arasında gerçekte nasıl aktığını netleştirin. Bir inşaat web uygulaması, saha sorularını, ofisten onayları ve değişime ayak uyduran bütçe güncellemelerini gerçek teslimatlar gibi yansıttığında başarılı olur.

Uygulamanın kimler için olduğunu tanımlayın

Çoğu inşaat ekibi tek bir “kullanıcı” değildir. v1'iniz birincil rolleri ve onların günlük olarak yapmaları gerekenleri adlandırmalı:

• Sahipler / yöneticiler: proje sağlığı, bütçe riski ve tahminler.
• Proje yöneticileri: taahhütler, değişiklik emirleri, RFI'lar, onaylar ve tamamlanma maliyeti.
• Şantiye süpervizörleri / ustabaşları: günlük kayıtlar, ilerleme güncellemeleri, sorunlar, fotoğraflar, zaman kaydı.
• Muhasebeciler: faturalar, maliyet kodları, iş maliyeti raporları, denetim izi.

Herkesi aynı anda memnun etmeye çalışırsanız, kimsenin sevmediği bir araç çıkarırsınız. Benimseme sağlayacak 1–2 rolü seçin (çoğunlukla PM + süper/ustabaşı) ve diğerlerini raporlama ile destekleyin.

Çözülecek ana sorunları listeleyin

Ağrı noktalarını iş akışındaki gerçek anlara eşleyin:

• Kaçırılan teslim tarihleri: takvimler sahadaki gerçeği yansıtmıyor; güncellemeler geç geliyor.
• Bütçe aşımları: maliyetler deftere, iş zaten değiştikten sonra yansıyor.
• Belirsiz taşeron durumu: uyumluluk, kapsam ve ilerleme dağınık e-postalarda yaşıyor.

Önemli başarı metriklerini belirleyin

Erken dönemde ölçülebilir çıktıları tanımlayın, örneğin:

• Daha az değişiklik-emri sürprizi (ör. onaylı değişikliklere bağlı maliyetlerin %si).
• Daha hızlı onaylar (talep ile onay arasındaki ortalama gün sayısı).
• Daha temiz raporlar (haftalık maliyet raporu üretme süresi; daha az manuel düzeltme).

“v1”de ne olması gerektiğine karar verin

v1'i uçtan uca iş akışını destekleyen en küçük sistem olarak ele alın: bir proje, bir bütçe, bir taşeron güncelleme döngüsü. İleri düzey tahminleme veya özel panolar gibi "iyi olur" özellikleri, benimsemeyi kanıtlayana kadar erteleyin.

Takip Etmeniz Gereken Temel Kullanım Senaryoları ve Veriler

İnşaat ekipleri tüm gün "yazılım kullanmaz"—onlar olaylara tepki verir: bir teslimat gecikti, bir taşeron PO değişikliği istiyor, bir usta treylerden saat kaydı gönderiyor, bir sahip maliyet güncellemesi istiyor. İlk kullanım senaryolarınız bu tetiklerle eşleşmelidir.

Yaşam döngüsünü ve önemli anları eşleyin

Şirketinizde işin nasıl aktığını basit bir zaman çizelgesiyle başlatın: ihale → işe başlama → yürütme → kapanış. Sonra her aşamanın içindeki kararları ve teslimleri işaretleyin—bunlar ilk kullanım senaryolarınızdır.

Örnekler:

• İşe başlama: proje oluştur, bütçeyi ayarla, PM/süper ata, taşeronları davet et
• Yürütme: taahhütlü maliyetleri, saha ilerlemesini, RFI'ları, değişiklik emirlerini, faturaları takip et
• Kapanış: retention, son teminat feragatları, punch list, nihai maliyet raporu

Temel nesneleri tanımlayın (sizin “gerçeğiniz”)

Çoğu inşaat web uygulaması, veri modeli insanların işten nasıl bahsettiğiyle uyumlu olup olmadığına göre başarılı olur ya da başarısız olur. Genellikle ihtiyacınız olacaklar:

• Projeler (konumlar, başlangıç/bitiş tarihleri, iş sahibi, genel yüklenici)
• Fazlar / maliyet kodları (iş maliyetlendirmesinin omurgası)
• Görevler / aktiviteler (bu hafta ne yapılıyor)
• Tedarikçiler / taşeronlar (şirketler ve iletişimler)
• Sözleşmeler / PO'lar (taahhütlü maliyet ve kapsam)

Roller, izinler ve onayları erken tanımlayın

İzinler şirket ve proje bazında çalışmalı (örn. bir taşeron yalnızca Proje A'daki sözleşmesini görebilmeli, Proje B'yi değil). Ayrıca onay yollarını şimdi listeleyin: değişiklik emirleri, faturalar ve zaman kayıtları genellikle net bir “gönder → incele → onayla → öde” zinciri gerektirir.

Çevrimdışı gerçeklikler için tasarlayın

Saha güncellemeleri gecikir, bağlam eksik olur: fotoğraflar, notlar ve kısmi miktarlar günlük spotty internet sonrası gelir. Şunları planlayın:

• Zaman damgalı kayıtlar (oluşturuldu vs gönderildi vs onaylandı)
• Doğru nesneye bağlanmış ekler (fotoğraflar, PDF'ler)
• Taslak olarak kaydedilebilen, senkronizasyona uygun formlar

Projeler, Bütçeler, Taşeronlar için Minimum Özellik Setini Tanımlayın

Ekranları tasarlamadan önce, bir PM'nin üç soruyu hızlıca cevaplayabilmesi için uygulamanızın neyi takip etmesi gerektiğine karar verin: Neredeyiz? Ne harcadık? Kim sorumlu? "Minimum" özellik seti küçük değildir—odaklıdır.

Projeler: ortak gerçek kaynağı

Her kayıt bir projeyi ekstra hesaplar olmadan tanımlamayı ve yönetmeyi sağlamalı. En azından şunları yakalayın: durum, başlangıç/bitiş tarihleri, konum, müşteri ve paydaşlar (PM, süpervizör, muhasebe, müşteri irtibatı).

Durumu basit tutun (örn. Önerilen → Aktif → Kapanış) ve tarihlerde yapılan değişiklikleri bir denetim iziyle düzenlenebilir yapın. Temel proje özet görünümü ekleyin; önemli metrikleri (bütçe sağlığı, son kayıt, açık sorunlar) tıklamaya zorlamadan gösterin.

Bütçeler: insanların açıklayabileceği bir model

İnşaat bütçe yönetimi için minimum "bir sayı" değildir. Birkaç tutarlı kova gerekir:

• Orijinal bütçe (baseline)
• Taahhütlü maliyetler (onaylanmış PO'lar/sözleşmeler)
• Gerçekleşenler (faturalar/zaman/maliyet kayıtları)
• Tamamlanma tahmini (en iyi mevcut tahmin)

Bu, tam bir muhasebe sistemi inşa etmeden iş maliyetlendirme kararlarını destekler. Hangi verinin hangi kovaya beslendiğini ve sayının nereden geldiğini açıkça gösterin.

Taşeronlar: risk ve ödemeleri yönetmek için yeterli bilgi

Taşeron yönetimi yazılımı, başlangıçta şunlarla başlamalı: kayda alma durumu, sigorta türleri ve bitiş tarihleri, iş kapsamı ve tarife (saatlik, birim veya anlaşmalı tarifeler).

Basit bir uyumluluk göstergesi ekleyin (örn. “Sigorta 14 gün içinde bitiyor”) ve ana iletişimleri saklayın. Puanlama fazlasına gitmeyin; birkaç yapılandırılmış alan ve notlar yeterlidir.

Belgeler: işe kanıt ekleyin

Belgeler e-posta dizilerinde kaldığında inşaat proje takibi bozulur. Minimum belge türleri: çizimler, şartnameler, fotoğraflar, günlük kayıtlar ve toplantı notları. Ana özellik, belgeleri bir projeye (ve ideal olarak bir bütçe satırına veya taşerona) bağlamaktır, böylece daha sonra bulunabilirler.

Denetim: kim neyi ne zaman değiştirdi

Bir MVP bile bütçe, taşeron uyumluluğu ve proje tarihleri için denetim izi gerektirir. Kullanıcı, zaman damgası, değişen alan ve eski/yeni değerler izleyin—bu anlaşmazlıkları önler ve kapanışı hızlandırır.

İnşaatla Uyumlu Bir Bütçeleme ve İş Maliyetlendirme Modeli Tasarlayın

Bir inşaat bütçesi yalnızca tek bir sayı değildir—paranın nasıl harcanacağı, onaylanacağı ve sonra açıklanacağına dair bir haritadır. Web uygulamanız, kestirmecilerin, proje yöneticilerinin ve muhasebenin maliyetler hakkında zaten düşündüğü şekilde tasarlanmalıdır.

İnsanların tanıdığı bütçe yapısıyla başlayın

Çoğu ekip şu hiyerarşiyi bekler:

• Proje → Faz (zemin hazırlığı, temel, kaba iskelet, MEP, bitişler)
• Faz → Maliyet kodları (CSI tarzı veya şirket içi kodlar)
• Maliyet kodu → Satır kalemleri (beton, donatı, işçilik, kira)

Ayrıca ödenekler (kapsam biliniyor, fiyat bilinmiyor) ve muhtemel beklenmeyenler (contingency) desteği ekleyin; kullanıcılar sapmayı açıklarken "planlanan" ile "yedek" parayı ayırmak isteyecektir.

Taahhütleri gerçekten harcamalardan ayrı takip edin

İş maliyetlendirmesi, parayı karar noktalarını yansıtan kovalara ayırdığınızda en iyi çalışır:

• Taahhütler: imzalı sözleşmeler, düzenlenmiş satınalma siparişleri, ve onaylı değişiklik emirleri. Bunlar "bunu harcamayı kabul ettik" tutarlarıdır.
• Gerçekleşenler: faturalar, makbuzlar, işçilik saatleri (zaman çizelgeleri) ve ekipman kullanımı. Bunlar "gerçekten harcadık" tutarlardır.

Bu ayrım, yaygın bir sorunu önler: bir proje faturalandırma gelene kadar bütçe altında görünür—sonra faturalar gelince hızla yükselir.

Tahminleme: hâlâ faydalı olan en basit model

Maliyet kodu başına pratik varsayılan:

• Tamamlanma tahmini = bugüne kadar gerçekleşenler + kalan taahhütler + tahmini kalan

Burada kalan taahhütler, onaylı sözleşmeler/PO'lar üzerindeki kalan tutardır, tahmini kalan ise kapsam tam taahhüt edilmemişse manuel girilen bir değerdir.

Ardından sapmaları erken işaretleyin:

• Varyans = tamamlanma tahmini − bütçe

Gerçekleşenler hâlâ düşük olsa bile bir maliyet kodunun üzerine doğru gittiğini görünür kılın.

Raporlama ayrıntı düzeyini kasıtlı seçin

Kullanıcıların hangi düzeyde toplayıp parçalayabileceğini kararlaştırın ve tutarlı tutun:

• Proje bazlı: yönetici görünümü, nakit akışı görüşmeleri
• Faz bazlı: PM görünümü, kapsam ve işlerin yönetimi için
• Maliyet kodu bazlı: muhasebe + maliyet kontrolü (sapma takibi için en iyi)

Eğer kullanıcılar bugün ayrıntılı maliyet kodları takip etmiyorsa, faz düzeyinde başlayın ve kademeli benimsemeye izin verin—çok erken ayrıntı dayatmak genellikle veri kalitesine zarar verir.

Taşeron Onboarding, Uyumluluk ve Performans Takibini Planlayın

Taşeronlar çoğu projenin motorudur, ancak onboarding ve uyumluluk elektronik tablolar ve e-posta dizileriyle yönetildiğinde gecikmeler ve maliyet sürprizleri de beraberinde gelir. Uygulamanız, bir taşeronu davet etmeyi, çalışmaya uygunluğunu doğrulamayı ve neler olduğunu net bir kayda almayı kolaylaştırmalı—işlemi kağıt işi haline getirmeden.

Güncel kalmayan profil oluşturmaktan kaçının

Projeler arasında yeniden kullanılabilir bir taşeron profiliyle başlayın. Temel detayları bir kez saklayın, sonra her yerde referans verin:

• İletişimler (ofis, PM, faturalama), tercih edilen iletişim kanalları, acil durum kontakları
• İş dal(lar)ı, hizmet bölgeleri, tipik ekip büyüklüğü
• W-9/vergi alanları (gerektiği kadar), ödeme koşulları, ödeme adresi bilgileri

Hatırlatmalı uyumluluk takibi

Uyumluluk, seferberlik öncesinde zaman kaybının olduğu yerdir. Belgeleri sadece dosya olarak değil yapılandırılmış veri olarak takip edin:

• Poliçe limitleri ve son kullanma tarihleriyle sigorta sertifikaları
• Güvenlik belgeleri ve gerekli eğitimler (proje bazlı veya şirket genelinde)
• Son kullanma öncesi otomatik hatırlatmalar ve gerekli öğeler eksikse "yeni işlere bloke" durumu

Kapsam, kilometre taşları ve retention

Kapsamı projeye bağlayın ki herkes taşeronun ne için sorumlu olduğunu görebilsin:

• Atanan görevler, teslimatlar, kilometre taşları ve retention koşulları
• Değişiklik emirleri ve onaylarına bağlantılar (böylece kapsam değişiklikleri kaybolmaz)

Müdahale edilebilecek performans sinyalleri

Performans takibini hafif ama kullanışlı tutun:

• RFI/submittal veya onay isteklerine yanıt süreleri
• Punch list tamamlama oranı ve yeniden iş notları
• Tarih, alan ve fotoğraflarla ilişkilendirilmiş kalite notları

Proje spesifik iletişim geçmişi

Mesajları, onayları ve dosya alışverişlerini proje kaydında yakalayın ki daha sonra denetlenebilir olsun—anlaşmazlık çıktığında en çok ihtiyaç duyulan şey budur. Basit bir zaman çizelgesi görünümü haftalar süren gelen kutusu aramalarının yerini alabilir.

Planlama, Günlük Kayıtlar ve Saha Raporlaması Ekleyin

Planlama ve saha raporlaması, bir inşaat web uygulamasını süperler ve PM'ler için "gerçek" yapar. Kilit nokta, v1'i telefonda hızlı kullanılabilir, projeler arasında tutarlı ve ofisin gerçekten raporlayabileceği kadar yapılı tutmaktır.

Planlama: hesap verebilirlik yaratan en hafif aracı seçin

Kullanıcılarınızın hangi tür bir takvim tutacağını belirleyin:

• Basit kilometre taşları (MVP için en uygun): ihale kazanımı, seferberlik, kaba iş tamam, denetimler, önemli tamamlanma.
• Takvim görünümü: yaklaşan denetimler, beton dökümleri, teslimatlar ve taşeron çalışma pencerelerini göstermek için iyi.
• Tam Gantt: sadece ekibiniz zaten Gantt içinde yaşıyorsa ve bağımlılıkları güncel tutacaklarsa ekleyin.

Pratik bir uzlaşı, kilometre taşları + önemli etkinliklerin takvimi olabilir. Notlar, sorumlu kişi ve "son güncelleme" zaman damgaları ekleyin.

Günlük kayıtlar: 2 dakikadan kısa sürede önemli olanı yakalayın

Bir günlük kayıt tek ekranda birkaç zorunlu alan içermeli:

• Hava (mümkünse konumdan otomatik doldurma)
• İşçi sayısı (iş dalına göre veya toplam)
• Teslimatlar (tedarikçi + gelen malzeme)
• Olaylar/güvenlik notları
• İlerleme notları (kısa, zaman damgalı)

Kayıtları tarih aralığı, proje ve yazar bazında aranabilir ve filtrelenebilir yapın. Ofis ekipleri bu kayıtları anlaşmazlıkları çözmek ve üretimi doğrulamak için kullanacak.

Saha yakalama: fotoğraflar, punch list ve temel RFI/submittal işlemleri

Fotoğraflar kolay olmalı: çek/yükle, sonra proje, konum/alan, tarih ve kategori ile etiketle (örn. “döküm öncesi”, “iskelet”, “hasar”). Etiketlenmiş fotoğraflar daha sonra değişiklik emri takibi ve kalite kontrolleri için kanıt olur.

Punch list öğeleri yapılandırılmış görevler olarak iyi çalışır: madde, atanan kişi, son tarih, durum ve fotoğraf kanıtı. Durumları basit tutun (Açık → Devam Ediyor → İnceleme Hazır → Kapandı).

RFI/submittal için v1'de tam bir doküman kontrol sistemi kurmaktan kaçının. Temelleri takip edin: numara, başlık, sorumlu taraf, son tarih ve durum (Draft/Sent/Answered/Closed) artı ekler.

Bir “kuzey yıldızı” metriği istiyorsanız: saha kullanıcılarının dizüstü yerine günlük kayıt + fotoğrafı tamamlayabilmesini hedefleyin.

UX Tasarımı: Yoğun Ekiplerin Anlayabileceği Panolar

İyi inşaat UX'i "daha fazla özellik"ten çok aynı soruları hızlı cevaplamaya yöneliktir: Bugün ne oluyor? Risk altında olan ne? Hangi onaylar bekliyor?

Proje panosunu günlük başlangıç noktası yapın

Proje panonuz sabah brifingi gibi okunmalı. Katıla yukarı katmanında şu temel bilgileri koyun:

• Ana tarihler (başlangıç, kilometre taşları, önemli tamamlanma)
• Bütçe sağlığı (taahhütlü vs harcanan vs tahmin)
• Açık riskler (yaşlanan RFI'lar, bekleyen değişiklik emirleri, güvenlik sorunları)
• Bekleyen onaylar (faturalar, CO'lar, zaman kayıtları)

Açık durum etiketleri kullanın (İzleniyor / Dikkat / Riskte) ve her kartı odaklanmış detay sayfasına tıklanabilir yapın—widget yığınlarından kaçının.

Bütçe görünümleri: varyanstan faturaya bir tıkla

Çoğu ekip önce basit bir maliyet kodu tablosu ister; varyans vurgularıyla yoruma gerek kalmadan. Drill-down kolay olsun:

• Maliyet kodu → taahhütler (PO/sözleşme) → faturalar → ödemeler

“Geçen haftadan ne değişti” küçük bildirimleri gösterin (yeni fatura yüklendi, CO onaylandı) ki bütçe bir hikaye anlatsın.

Taşeron görünümleri: kovalamayı azaltın

PM'lere hızlı bir “kim aktif, kim bloke” görünümü verin: eksik sigorta, süresi dolmuş W-9, gecikmiş teslimatlar, eksik zaman çizelgeleri. Kritik belgeler eksikse bir taşeron asla "aktif" olmamalıdır.

Mobil öncelikli saha kullanıcıları için (sevimsizleştirmeden)

Saha ekranları tek baş parmak hareketleriyle yapılacak işlemler olmalı: fotoğraf ekle, günlük not ekle, punch item oluştur, konum etiketle, sahip ata. Büyük dokunmatik hedefleri varsayılan yapın ve çevrimdışı taslakları destekleyin.

Erişilebilirlik temelleri

Okunabilir yazı tipleri, tutarlı terminoloji ve durum renklerinin yanında metin/ikon uyarıları kullanın. Ofis kullanıcıları için tablolarla yaşayanlar adına klavye navigasyonunu destekleyin.

Basit, Güvenli Bir Teknik Mimari Seçin

Bir inşaat web uygulaması güvenilir olmak için karmaşık bir yığını gerektirmez. Amaç, ekibinizin hızlıca yayınlayabileceği, güvenle çalıştırabileceği ve saha gerçekten ne kullandığını öğrendikçe genişletebileceğiniz bir kurulumdur.

Önerilen temel: web uygulaması + API + veritabanı + dosya depolama

Temiz, yaygın bir desen:

• Web uygulaması (UI): PM'lerin, muhasebenin ve şantiye ekiplerinin çalışma, onay ve güncelleme yaptığı yer.
• API (sunucu): bütçeleri, izinleri ve iş akışlarını doğrulayan "kurallar motoru".
• Veritabanı: projeler, taşeronlar, maliyetler ve denetim geçmişi için gerçek kaynak.
• Dosya depolama: çizimler, faturalar, teminat feragatları, fotoğraflar ve imzalı değişiklik emirleri için.

Bu parçaları ayırmak, daha sonra ölçeklerken her şeyi yeniden tasarlamaya gerek bırakmaz.

Eğer amacınız kod temeline aylar harcamadan iş akışlarını hızlıca doğrulamaksa, prototiplemek ve ilk kullanılabilir sürümü daha hızlı yayımlamak için Koder.ai gibi bir vibe-coding platformu yardımcı olabilir—halen gerçek bir mimari (React web UI, Go servisleri ve PostgreSQL) üretip hazır olduğunuzda kaynak kodu dışa aktarabileceğiniz bir temel sağlar.

Kimlik doğrulama: basit başlayın, kiracı ayrımını zorunlu kılın

E-posta/şifre ile başlayın; güçlü parola politikaları ve isteğe bağlı MFA uygulayın. Daha büyük müşteriler talep ettiğinde SSO (Google/Microsoft/SAML) ekleyin.

En önemlisi, baştan itibaren çoklu kiracı ayrımı uygulayın: her kayıt bir şirkete (tenant) ait olmalı ve her sorgu o kiracıya göre sınırlandırılmalı. Bu, lansmandan sonra düzeltmesi zor olan "şirketler arası veri sızıntılarını" önler.

Yetkilendirme: şirket ve proje bazlı rol tabanlı erişim

İnşaat ekiplerinin farklı görünümlere ihtiyacı vardır:

• Şirket düzeyi roller (sahip/admin/muhasebe)
• Proje düzeyi roller (PM, süpervizör, taşeron)

Role-based access control (RBAC) uygulayın; hem şirket üyeliği hem de proje ataması onaylanmadan değişiklik emirleri onaylamak veya maliyet raporu dışa aktarmak gibi işlemlere izin vermesin.

Dosya depolama: herkese açık dosyalar değil, güvenli bağlantılar

Belgeleri yönetilen depolamada saklayın ve erişimi zaman sınırlı, imzalı URL'ler ile sağlayın. Dosya meta verilerini (kimin yüklediği, hangi proje, hangi maliyet kodu) veritabanında tutun ki dosyalar aranabilir ve denetlenebilir kalsın.

Etkinlik günlüğü: onaylar ve finansal değişiklikler için değiştirilemez olaylar

Para veya taahhütleri etkileyen herhangi bir işlem (bütçe düzenlemeleri, onaylar, pay uygulamaları, değişiklik emirleri) için eklemeye dayalı (append-only) bir etkinlik günlüğü yazın. Birisi "Bunu kim, ne zaman onayladı?" diye sorduğunda güvenilir bir iziniz olsun.

Pratik Bir Veritabanı Şeması ve İlişkiler Oluşturun

İyi bir şema "mükemmel modelleme"den çok, ekibinizin her gün sorduğu soruları desteklemeyle ilgilidir: Bütçe vs taahhüt nedir? Ne değişti? Kim sorumlu? Ne bloke?

Temel varlıklar (uygulamanın omurgası)

En azından şu tabloları isteyeceksiniz:

• Company: kiracı sınırı. Her tablodaki her satır bir şirkete ait olmalı.
• User: giriş yapan kişiler (PM'ler, muhasebe, süpervizörler).
• Project: her şeyin konteyneri.
• CostCode: kodlama yapınız (CSI, iç kodlar, fazlar).
• BudgetLine: projenin planlanan dolarları, genellikle maliyet koduna göre.
• Vendor: taşeronlar, tedarikçiler ve danışmanlar.

Erken aşamada iyi çalışan basit ilişki modeli:

• Company 1—N Project
• Project 1—N BudgetLine
• BudgetLine N—1 CostCode
• Project 1—N Vendor (veya Company 1—N Vendor ile proje atamaları sonra)

Finansal varlıklar (paranın nasıl hareket ettiği)

Gerçek iş maliyetlendirmesini takip etmek ve elektronik tabloları önlemek için bazı finansal kayıtlar ekleyin:

• Commitment: “bu tedarikçiye $X ödemeyi planlıyoruz” kaydı (genellikle bir sözleşme veya PO). Project, Vendor ve genellikle bir veya daha fazla maliyet koduna bağlanır.
• ChangeOrder: bütçeyi/taahhütleri değiştiren öğeler. scope, amount, status ve neyi değiştirdiğine referans içerir.
• Invoice: tedarikçinin faturaladığı şey (genellikle bir taahhütle ilişkilidir). fatura numarası, dönem ve onay durumu yakalanır.
• Payment: gerçekte yapılan ödeme (kısmi ödemeler önemli).
• TimeEntry: saatler ve işçilik maliyeti; Project, User (veya çalışan) ve CostCode ile ilişkilendirin.

İpucu: her şeyi tek bir “işlem” tablosuna zorlamayın. Taahhütleri, faturaları ve ödemeleri ayrı tutmak onaylar ve raporlama açısından daha netlik sağlar.

Operasyonel varlıklar (sahada neler oldu)

Bunlar maliyetlerin ve takvim etkilerinin arkasındaki bağlamı sağlar:

• DailyLog (hava, işgücü, notlar)
• Photo (projeye ve isteğe bağlı olarak günlük kayda, punch item'a veya RFI'ya bağlı)
• PunchItem (kusur/kapanış görevleri)
• RFI ve Submittal (durum, son tarihler ve atamalar ile)

Durum enum'ları, zaman damgaları ve denetlenebilirlik

İnşaat iş akışları net durumlara bağlıdır. Tablolarda durum enum'ları ve standart zaman damgaları kullanın:

• Durum örnekleri: draft, submitted, approved, rejected, voided, paid, closed.
• Zaman damgaları: created_at, updated_at, artı submitted_at, approved_at, paid_at gibi iş akışı zamanları.
• Kararların önemli olduğu yerlerde created_by_user_id ve updated_by_user_id ekleyin (değişiklik emirleri, faturalar, RFI'lar).

İndeksleme ve arama temelleri

Kullanıcıların gün boyunca tıklayacağı yaygın filtreleri optimize edin:

• Yabancı anahtarlar için indeksler: project_id, vendor_id, cost_code_id, created_at.
• Liste görünümleri için bileşik indeksler ekleyin, örn. RFIs ve faturalar için (project_id, status, updated_at).
• Temel arama alanları: tedarikçi adı, proje adı/numarası, maliyet kodu kodu/açıklaması, belge etiketleri.

Şemayı küçük, tutarlı ve sorgulanması kolay tutun—panolarınız ve dışa aktarımlarınız minnettar olacaktır.

Entegrasyonları ve Veri İçeri Aktarmayı Aşırıya Kaçmadan Planlayın

Entegrasyonlar bir inşaat web uygulamasını "tam" hissettirebilir, ama aynı zamanda zaman çizelgenizi yiyebilir. v1 için, tekrar girme ve kaçırılan iletişimi önleyenlere odaklanın—sonra genişleme için alan bırakın.

v1 için gerekli entegrasyonlar

İki zorunlu ile başlayın:

• Muhasebe dışa aktar/ithalat: QuickBooks/Xero alanlarına eşlenen basit bir CSV çıkışı bile bütçe, tedarikçi faturası ve maliyet kodlamasını yeniden yazma gereğini azaltır. Gerçekleri geri içe aktaracaksanız, tutarlı maliyet kodları ve iş ID'leri kullanın.
• E-posta bildirimleri: değişiklik emirleri, onaylar ve gecikmiş öğeler için güncellemeler gönderin. Karmaşık bir mesajlaşma sistemi kurmayın—kayıda net bağlantılar içeren tetiklenmiş e-postalar yeterli olacaktır.

Opsiyonel entegrasyonlar (faz 2 olarak düşünün)

Bu değerli ama genellikle ürünü kanıtlamak için gerekli olmayanlar:

• Bordro (zaman çizelgelerinin bordroya dönüşümü karmaşıktır ve şirkete göre değişir)
• E-imza (değişiklik emirleri ve alt yüklenici sözleşmeleri için harika)
• Bulut depolama (Google Drive/Dropbox/SharePoint) planlar, fotoğraflar ve uyumluluk belgeleri için

İlk günden çalışacak veri içe aktarma

Çoğu ekip hemen mevcut veriyi getirmek isteyecektir. Şunlar için CSV şablonları sağlayın:

• Projeler
• Maliyet kodları
• Tedarikçiler/taşeronlar
• Bütçeler (orijinal bütçe ve revizyonlar dahil)

İçe aktarmaları "hoşgörülü" yapın: satır ön izlemesi, hata işaretleme ve kısmi başarı ile bir hata raporu sunun.

Gelecek entegrasyonlar için webhook/olay tanımlayın

Entegrasyonları şimdi göndermeseniz bile project.created, budget.updated, invoice.approved, change_order.signed gibi olayları tanımlayın. Olay yüklerini saklayın ki gelecekteki bağlayıcılar ne olduğunu tekrar oynatabilsin.

Manuel geri dönüş planları yazın

Ertelediğiniz her entegrasyon için manuel iş akışını yazın: “Haftalık CSV dışa aktar”, “Faturaları bir maliyet koduna yükle”, “Onay e-postalarını ilet”. Net bir geri dönüş, v1'i gerçekçi kılar ve operasyonları engellemez.

Güvenlik, İzinler ve Veri Saklama Politikalarını Ele Alın

İnşaat uygulamaları para, sözleşmeler ve kişisel bilgilerle çalışır—bu yüzden güvenlik lansmandan sonra yapılacak bir iş olmamalı. Amaç basit: doğru kişiler doğru veriyi görsün, işlemler izlenebilir olsun ve hiçbir şey kaybolmasın.

Vazgeçilemez güvenlik temelleri

En yaygın olayları önleyen temellerle başlayın:

• İletişimde şifreleme: her yerde HTTPS zorlayın (iç API'lar dahil) ve HSTS etkinleştirin.
• Güvenli oturumlar: kısa ömürlü oturumlar, güvenli çerezler, CSRF koruması ve paylaşılan cihazlar için hareketsizlikte otomatik çıkış.
• Güçlü parola kuralları: minimum uzunluk, ihlal olmuş parolaları engelleme ve onay rolleri için SSO veya MFA desteği.

Kiracı izolasyonu (şirketler arası veri koruma)

Birden çok şirket uygulamayı kullanıyorsa, kiracı ayrımının saldırıya uğrayabileceğini varsayın—istemeden veya kasıtlı. Veri katmanında ayrım uygulayın (her kayıt şirketle ilişkilendirilsin) ve şunlarla destekleyin:

• Başka bir kiracının projelerini/bütçelerini almaya çalışan otomatik testler
• Kiracı filtreleri eksik olan endpoint'leri tespit eden kod inceleme "imkansız sorgu" kontrolleri
• Dışa aktarmalar olduğunda net denetim günlükleri

Onay süreçlerine uygun izinler

İzinler uzun bir anahtar listesi olmamalı. Parayı hareket ettiren kararlar üzerinde odaklanın:

• Kim maliyetleri onaylayabilir, değişiklik emirleri çıkarabilir ve bütçeleri düzenleyebilir
• Kim gönderir vs onaylar (zaman çizelgeleri ve faturalar)
• Kim projeyi kapatabilir veya geçmiş dönemleri kilitleyebilir

Düzenli izin gözden geçirmeleri planlayın (aylık/çeyreklik) ve yöneticiler için bir “erişim raporu” sayfası tutun.

Yedekler ve veri saklama (geri yükleme tatbikatlarıyla)

Yedekler sadece geri yüklenebiliyorsa önemlidir. Rutin yedekler çalıştırın ve geri yüklemeyi periyodik olarak test edin.

Veri tipi başına saklama kuralları belirleyin: finansal kayıtları günlük kayıtlarından daha uzun saklayın ve bir proje arşivlendiğinde ne olacağını tanımlayın. Politikayı yardım merkezinizde belgeleyin.

Uyumluluk ve gizlilik: daha az topla, daha çok kaydet

Gerekli kişisel veriyi saklayın (isimler, e-postalar, gerekli uyumluluk belgeleri). Hassas işlemler için (dışa aktarma, izin değişiklikleri, bütçe düzenlemeleri) erişim günlüklerini tutun ki olaylar hızlıca araştırılabilsin.

Aşamalarla Yayınlayın: MVP, Pilot ve İterasyon Planı

Bir inşaat web uygulaması, PM'ler, ofis ve saha tarafından her gün kullanıldığında başarılı olur. Bunu başarmanın en kolay yolu net aşamalar halinde yayınlamak, gerçek bir projede doğrulamak ve insanların gerçekten yaptığına göre iterate etmektir (sizin düşündüğünüz değil).

Aşama 1: MVP ("bir projeyi çalıştırabilen" sürüm)

Yapım sırasını basit ve kasıtlı tutun: projeler → bütçeler → taşeronlar → onaylar → raporlar. Bu sıra, bir işi oluşturup bütçe koyup tedarikçiyi atayıp değişiklikleri onaylayıp paranın nereye gittiğini görmenizi sağlar.

MVP için bağımlı olabileceğiniz birkaç güvenilir iş akışı seçin:

• Projeleri ve maliyet kodlarını oluşturma
• Bütçe satırlarını ve taahhütlü maliyetleri girme
• Taşeron kapsamı, zaman çizelgeleri ve faturaları izleme
• Temel değişiklik emri takibi ile onaylar
• Basit raporlar (bütçe vs gerçekleşen, taahhütler, bekleyen onaylar)

Zaman çizelgesini kısaltmak istiyorsanız, pilot sürümü Koder.ai gibi bir platformda inşa etmeyi düşünebilirsiniz—ekranlar ve iş akışları sohbet aracılığıyla iterasyonla geliştirilebilir, planning mode ile v1 kapsamı kilitlenir ve yine de üretime uygun temel (React, Go, PostgreSQL) ile kaynak kodu dışa aktarılabilir.

Aşama 2: Test planı (pahalı hatalara odaklanın)

İnşaat uygulamaları toplamlar eşleşmediğinde veya yanlış kişinin bir şeyi onayladığında başarısız olur. Öncelik verin:

• Hesaplamalar için birim testleri (bütçe toplanmaları, taahhüt vs gerçekleşen, değişiklik emri toplamları)
• İş akışı testleri (taslak → gönderildi → onaylandı/reddedildi; denetim izi)
• İzin testleri (taşeronun ne görebileceği vs PM vs muhasebe)

Aşama 3: Pilot yayılımı (gerçek kullanıcılar, gerçek baskı)

Bir şirket ve bir proje ile başlayın. Geri bildirimi haftalık toplayın ve spesifik örnekler isteyin: “Ne yapmaya çalıştınız? Nerede bozuldu? Bunun yerine ne yaptınız?”

Kısa eğitim materyalleri oluşturun: rol başına kısa kontrol listeleri ve 2 dakikalık adım adım videolar (PM, süpervizör, muhasebe, taşeron). Amacınız tekrar edilebilir onboarding, uzun eğitim oturumları değil.

Aşama 4: Sonuçlara göre iterasyon

Çıktıları ölçün ve iterasyon yapın: daha hızlı onaylar, daha az bütçe sürprizi, daha temiz faturalar, daha az elektronik tablo el değişimi. Yeni özellikleri yalnızca pilot ekip kullanım desenleri ve nerede zaman kaybettikleri haklı çıkardığında ekleyin—backlog'unuz pilot ekibin en çok dokunduğu ve zaman kaybettikleri alanlara göre şekillenmelidir.