Bir web sitesi ya da mobil uygulama işi için teklif alırken ilk bakılan yer fiyat satırı oluyor. Anlaşılır bir refleks. Ama işin içinden geçmiş biri olarak söyleyebilirim: iki teklif arasındaki asıl fark, çoğu zaman rakamda değil, o rakamın neyi kapsadığını anlatan paragraflarda saklı. Aynı işi 30 bin liraya da yazabilirsiniz, 90 bin liraya da; belirleyici olan neyin dahil olduğu, neyin "sonra konuşuruz" rafına bırakıldığı.

Ege'de farklı sektörlerden firmalarla çalışırken en sık duyduğumuz cümlelerden biri şu: "Fiyat şuydu ama sonunda başka çıktı." Neredeyse hiçbirinde karşı tarafın kötü niyeti yok. Sadece teklif, işin sınırlarını çizmemiş. Bu yazıda sabit fiyatın hangi şartlarda gerçekten sabit kaldığını, teklifte hangi maddelerin mutlaka yazılı olması gerektiğini konuşacağız.

"Sabit fiyat" neden bazen sabit kalmıyor

Sabit fiyat bir vaat değil, bir denklemdir. Denklemin bir tarafında bedel, diğer tarafında kapsam durur. Kapsam bulanıksa bedelin sabitliği de bulanıklaşır. Proje ortasında "bu da olsun" diyen müşteri ile "bu kapsam dışı" diyen ajans arasındaki gerginliğin kaynağı neredeyse her zaman aynı: başta yazılmamış bir madde.

Kapsamı bulanık bırakan tipik ifadeler şunlar:

"Kurumsal web sitesi tasarımı" (kaç sayfa, hangi tipte sayfalar?)
"Mobil uyumlu" (hangi cihaz genişliklerinde test edilecek?)
"SEO uyumlu altyapı" (teknik SEO mu, içerik optimizasyonu mu?)
"Gerekli revizyonlar" (kaç tur, hangi aşamada?)
"İçerik girişi yapılacaktır" (metni kim yazıyor, görseli kim sağlıyor?)

Bu cümleler yanlış değil, eksik. Ve eksik teklif, ilerleyen haftalarda iki tarafı da zorlayan bir müzakereye dönüşüyor.

Sayfa sayısı değil, sayfa tipi konuşulmalı

Teklifte "8 sayfa" yazması tek başına bir şey anlatmaz. Bir iletişim sayfası ile filtreli, çoklu kategori destekli bir ürün listeleme sayfası aynı iş değildir. Doğru yaklaşım, sayfaları tipe göre ayırmaktır:

Benzersiz tasarım gerektiren sayfalar: ana sayfa, hizmet detay şablonu, hakkımızda, iletişim.
Şablondan çoğalan sayfalar: blog yazısı, ürün detayı, referans detayı. Bunların ilki tasarlanır, gerisi aynı şablonla üretilir.
Fonksiyonel ekranlar: arama sonuçları, filtreleme, form sonuç ekranları, üyelik alanları.

Bu ayrım yapıldığında "bir sayfa daha ekleyelim" talebinin maliyeti de kendiliğinden netleşir. Şablondan çoğalan bir sayfa çoğu zaman ek ücret gerektirmez; yeni bir fonksiyonel ekran gerektirir.

Sayfa sayısı yerine sayfa tipini konuşmak, kapsamı baştan netleştiriyor.

İçeriği kim hazırlıyor sorusu

Projelerin gecikme sebeplerini sıralasak, ilk sıralarda içerik beklemek vardır. Metinler, ürün fotoğrafları, kurumsal görseller, ekip bilgileri, referans listesi... Bunlar tasarımın gerçek hammaddesi. Teklifte içerik sorumluluğu yazılı değilse iki taraf da diğerinin hazırlayacağını varsayar.

Net bir teklif şunu söyler: metinler müşteri tarafından Word ya da Google Doküman olarak sağlanır; ajans yerleşim, düzenleme ve başlık optimizasyonunu üstlenir. Ya da tersi: metin yazımı da kapsamdadır ve şu kadar sayfa için geçerlidir. Hangisi olduğu önemli değil, yazılı olması önemli.

Aynısı görseller için de geçerli. Stok görsel kullanılacaksa lisans bedeli kimde? Ürün çekimi gerekiyorsa bu ayrı bir kalem mi? Grafik tasarım tarafında logo, kurumsal kimlik ve görsel üretimi ayrı bir uzmanlık; web paketinin içine "nasılsa hallederiz" diye sıkıştırıldığında her iki iş de zarar görüyor.

Revizyon turu tanımlanmalı

"Sınırsız revizyon" cümlesi kulağa cömert gelir ama pratikte kimseye yaramaz. Sınırsız revizyon, projenin bitiş tarihini de sınırsız yapar. Sağlıklı olan, revizyonun aşamalara bağlanmasıdır:

Tasarım onayı aşamasında 2 tur revizyon.
Geliştirme sonrası kontrol aşamasında hata düzeltmeleri (revizyon sayılmaz, ayıp giderme kapsamındadır).
Yayın öncesi son okuma ve içerik düzeltmeleri.

Burada kritik ayrım şu: hata düzeltmesi ile fikir değişikliği aynı şey değil. Butonun mobilde taşması hatadır, düzeltilir. "Ana sayfayı komple başka bir yapıya çevirelim" fikir değişikliğidir ve yeni bir kapsamdır. Teklif bu ayrımı açıkça yazmalı.

Üçüncü taraf hizmetler ve entegrasyonlar

Sanal POS, kargo entegrasyonu, e-fatura, SMS doğrulama, harita servisleri, canlı destek modülleri... Bunların çoğu aylık ya da işlem başına ücretli servisler. Ajans entegrasyonu yapar, ama servisin kendi bedeli müşteriye aittir. Bu, teklifte açıkça yazılmadığında ilk faturada şaşkınlık yaratıyor.

Doğru teklif şu formatta olur: "X sanal POS entegrasyonu geliştirme bedeline dahildir. Banka komisyon oranları ve varsa yıllık üyelik bedeli müşteriye aittir." Bir cümle, ileride yaşanacak yanlış anlaşılmayı baştan çözer.

Yıllık kalemler: barındırma, domain, güncelleme

Web projelerinde en sık atlanan kısım ilk yıldan sonrası. Site teslim edilir, herkes memnundur, on ikinci ayda barındırma yenileme faturası gelir. Sonra SSL, sonra alan adı, sonra altyapı güncellemesi. Toplandığında proje bedelinin küçümsenmeyecek bir yüzdesine ulaşabiliyor.

Biz bu kalemleri paketlerin içine dahil ederek çalışıyoruz: barındırma, alan adı ve güncellemeler pakete dahil, sonradan ayrı bir sürpriz kalem çıkmıyor. Bunu bir üstünlük iddiası olarak değil, kapsam netliğinin doğal sonucu olarak söylüyorum. Müşteri yıllık toplam maliyetini baştan biliyorsa bütçesini de doğru kurar.

Teklifte bu bölüm yoksa sormak gerekiyor: barındırma nerede, kimin adına? Alan adı kimin hesabında kayıtlı? Güncellemeler ne sıklıkla ve neyi kapsıyor? Son soru özellikle önemli, çünkü "güncelleme" kelimesi hem içerik değişikliğini hem altyapı yamalarını anlatmak için kullanılıyor ve bu ikisi bambaşka işler.

Barındırma, alan adı ve güncelleme kalemleri teklifte yazılı olmalı.

Mobil uygulamada kapsam nasıl yazılır

Mobil tarafta kapsam netliği daha da kritik, çünkü platform sayısı, mağaza süreçleri ve arka uç gereksinimleri işin hacmini hızla değiştirebiliyor. Teklifte olması gerekenler:

Hangi platformlar? iOS, Android ya da her ikisi.
Tek kod tabanı mı, iki ayrı native geliştirme mi? Biz Flutter ile tek kod tabanından iki platforma çıkıyoruz; bu hem bütçeyi hem de sonraki güncellemelerin süresini doğrudan etkiliyor.
Mağaza yayın süreci kapsamda mı? Apple ve Google geliştirici hesaplarının yıllık bedelleri kimde?
Arka uç (API) var mı, yoksa sıfırdan mı kurulacak?
Bildirim altyapısı, analitik, çökme raporlama araçları dahil mi?

Kendi ürünlerimizi de geliştirdiğimiz için bu kalemlerin gerçekte ne kadar zaman aldığını tahminle değil, deneyimle yazıyoruz. Amatör Arena gibi kendi platformumuzda mağaza güncellemesinden bildirim altyapısına kadar her adımı biz yönettiğimiz için, teklifteki süreler gerçekçi çıkıyor. Yaptığımız işlere bakarken sadece görsele değil, arkadaki yapının karmaşıklığına da bakmanızı öneririm.

Değişiklik talebi geldiğinde ne oluyor

Kapsam netliği, hiç değişiklik olmayacağı anlamına gelmiyor. Aksine, iyi bir teklif değişikliğin nasıl yönetileceğini de yazar. Pratikte işleyen yöntem şu:

Talep yazılı olarak iletilir.
Kapsam içi mi, kapsam dışı mı değerlendirilir ve bu değerlendirme müşteriyle paylaşılır.
Kapsam dışıysa süre ve bedel etkisi net bir cümleyle bildirilir.
Onay gelirse uygulanır, gelmezse mevcut plana devam edilir.

Bu döngü bürokrasi gibi görünebilir ama aslında ilişkiyi rahatlatıyor. Müşteri istediğini söylemekten çekinmiyor, ajans da her ek talebi sessizce yüklenmek zorunda kalmıyor. Aynı iş günü içinde yanıt verme alışkanlığımızın bir sebebi de bu: değerlendirme beklerken proje durursa, gecikmenin faturası ikimize birden çıkıyor.

Teklifi okurken sorulacak sorular

Hangi ajanstan teklif alırsanız alın, şu soruların cevabı belgede yazılı olmalı:

Kaç ve hangi tipte sayfa/ekran dahil?
Metin ve görsel içeriği kim sağlıyor?
Kaç tur revizyon var, hangi aşamalarda?
Hangi üçüncü taraf servisler kullanılacak, bedelleri kimde?
Barındırma, alan adı, SSL ve güncellemeler ilk yıl ve sonrası için ne durumda?
Teslim sonrası siteyi kim yönetecek, panel eğitimi veriliyor mu?
Kaynak dosyalar ve erişim bilgileri kimin mülkiyetinde?
Kapsam dışı taleplerde nasıl bir yol izleniyor?

Son maddelerden birine ayrı bir parantez açayım. Teslim sonrası siteyi yönetememek, işletmeler için sessiz bir maliyet. Küçük bir metin değişikliği için her seferinde ajansa yazmak zorunda kalmak hem yavaş hem gereksiz. Biz teslimde panel eğitimi veriyoruz; amaç müşterinin kendi içeriğine kendi hakim olması. Bu da aslında bir kapsam netliği meselesi: hangi işi kimin yapacağı baştan belli oluyor.

Netlik, güvenin en ucuz yolu

Teklif belgesi bir satış aracı değil, bir çalışma anlaşmasının taslağıdır. Ne kadar sıkıcı ve detaylı görünürse, proje o kadar sakin ilerler. Kapsamı net yazılmış bir teklif, sabit fiyatı gerçekten sabit kılar; çünkü iki taraf da aynı işi konuştuğunu bilir.

Bir proje için fiyat araştırıyorsanız, gelen teklifleri yan yana koyup önce rakamlara değil, kapsam bölümlerine bakın. Hangisi daha çok soruyu baştan cevaplıyorsa, süreçte sizi daha az yoracak olan odur. Aklınızdaki işi konuşmak, kapsamı birlikte çıkarmak isterseniz bize yazabilirsiniz; ilk adım her zaman ne yapılacağını netleştirmek oluyor.

Teklifte kapsam netliği: sabit fiyat hangi şartlarda gerçekten sabittir?