Sabit kapsam, tek muhatap, ölçülebilir teslim kriterleri ve yayın sonrası sahiplenme. Bizi tercih etmenizi sağlayan somut çalışma alışkanlıklarımız.
Bir web projesinin başarısız sayılmasının en yaygın nedeni kod hatası değil, beklenti farkıdır. Müşteri on beş sayfalık bir site beklerken ajans altı şablon üzerinden ilerler; müşteri ürün filtreleme bekler, teklifte sadece listeleme yazar. Bu farkın ortaya çıktığı an genellikle teslim günüdür ve o noktada iki taraf da haklıdır.
Bu yüzden her projeye yazılı bir kapsam dokümanıyla başlıyoruz. Dokümanda sayfa listesi, ekran listesi, entegrasyonlar, içerik sorumluluğu, revizyon sayısı, tarayıcı ve cihaz desteği, teslim biçimi ve kapsam dışı maddeler tek tek yer alıyor. Doküman onaylanmadan tasarıma başlamıyoruz. Bu, ilk hafta biraz yavaş ilerlemek anlamına geliyor; buna karşılık projenin ortasında yön değiştirme ihtimalini büyük ölçüde ortadan kaldırıyor.
Her projeye bir proje yöneticisi atıyoruz. Talebinizi, geri bildiriminizi, onayınızı ve şikâyetinizi tek kişiye iletiyorsunuz. Bu kişi ekip içindeki dağıtımı yapıyor, süre etkisini hesaplıyor ve size geri dönüyor.
Bunun karşılığı şu: "tasarımcıya söyledim ama yazılımcı duymamış" durumunun ortadan kalkması. Ayrıca her karar yazılı bir kayda dönüşüyor. Proje bittikten altı ay sonra "şu alanın neden böyle çalıştığını" sorduğunuzda, kararın hangi tarihte, kimin talebiyle ve hangi gerekçeyle alındığını gösterebiliyoruz.
"Site hızlı olacak" cümlesi bir teslim kriteri değildir. Biz kriterleri ölçülebilir yazıyoruz. Örneğin bir kurumsal site projesinde teslim şartları arasında şunlar bulunur: mobil Lighthouse performans skorunun belirlenen eşiğin üzerinde olması, Core Web Vitals metriklerinin (LCP, INP, CLS) saha verisinde "iyi" aralığına oturması, tüm sayfaların geçerli bir canonical etiketi taşıması, form gönderimlerinin hem ekrana hem e-postaya düşmesi ve klavye ile tüm menülerin gezilebilmesi.
Bu kriterler teslim gününde birlikte kontrol ediliyor. Karşılanmayan bir madde varsa iş teslim edilmiş sayılmıyor. Ölçüm sonuçlarını ekran görüntüsüyle değil, tekrar üretilebilir raporlarla paylaşıyoruz; aynı testi siz de çalıştırabilirsiniz.
Tasarımı bir ajanstan, kodlamayı başka bir firmadan aldığınızda ortaya çıkan tipik sorun şudur: tasarım dosyasında güzel duran bir bölüm, gerçek içerik girildiğinde bozulur. Üç kelimelik başlık için tasarlanmış bir kart, on iki kelimelik gerçek başlıkla taşar. Tasarımcı "kodlayan yanlış uygulamış", geliştirici "tasarım gerçekçi değil" der.
Bizde tasarımcı ve geliştirici aynı toplantıdadır. Tasarım aşamasında en uzun olası metinle, en kısa metinle ve görsel yokken nasıl görüneceği birlikte kararlaştırılır. Bileşen kütüphanesi tasarım tarafında ne ise kod tarafında da odur; ikisi arasında çeviri kaybı olmaz.
Yayına alma anı, sorunların değil, sorunların görünür olmaya başladığı anın işaretidir. Gerçek kullanıcılar gerçek cihazlarla girmeye başladığında beklenmedik davranışlar çıkar: belirli bir tarayıcı sürümünde bozulan bir form, yavaş bir mobil bağlantıda geç yüklenen bir görsel, arama motorunun beklenmedik bir sayfayı dizine alması.
Bu yüzden yayından sonraki ilk otuz günü projenin bir parçası sayıyoruz. Bu sürede çıkan hataları ücretsiz gideriyoruz, arama konsolu ve analitik kayıtlarını izliyoruz, ilk hafta ve ilk ay sonunda kısa birer durum notu iletiyoruz. Bakım anlaşması yapmasanız bile bu otuz gün her projeye dahildir.
Sizin. Proje sonunda kod deposu, veri tabanı yedeği, tasarım kaynak dosyaları, ortam değişkenlerinin listesi ve dağıtım adımları size devredilir. Alan adı ve barındırma hesapları sizin adınıza açılır; bizim hesaplarımız üzerinde tutulmaz.
Bunu bir pazarlama vaadi olarak değil, sağlıklı bir çalışma ilişkisinin şartı olarak görüyoruz. Müşterisini teknik olarak kilitleyen bir tedarikçi, ilişkiyi hizmet kalitesiyle değil bağımlılıkla sürdürüyor demektir. Bizimle çalışmaya devam etmenizi istiyoruz; ama devam etmemeyi seçtiğinizde bunun maliyeti sıfır olmalı.
SEO tarafında "ilk sıraya çıkarırız" demiyoruz; hiçbir ajansın bunu garanti edecek yetkisi yok. Bunun yerine hangi çalışmaları yapacağımızı, hangi metrikleri takip edeceğimizi ve ne kadar sürede ilk sinyalleri görmeyi beklediğimizi yazıyoruz.
Yazılım tarafında da benzer davranıyoruz. Bir entegrasyonun karşı taraftaki API belgelerine bağlı olduğunu, belgelerin eksik olması hâlinde sürenin uzayabileceğini baştan söylüyoruz. Kötü haberi geç vermek, kötü haberin kendisinden daha çok zarar veriyor.
Her işin tek seferde tam kapsamla yapılması gerekmiyor. Bütçe sınırlıysa projeyi fazlara bölüyoruz. İlk fazda işletmenin gelirine doğrudan katkı yapan çekirdek yapıyı kuruyoruz: satış ya da başvuru akışı, temel içerik sayfaları, ölçümleme ve arama motoru altyapısı. Görsel zenginleştirmeler, ikincil modüller ve otomasyonlar ikinci faza kalıyor.
Bu yaklaşım hem riski azaltıyor hem de ikinci fazın kararlarını tahmine değil gerçek kullanıcı verisine dayandırmanızı sağlıyor. İlk fazın analitik verisi, ikinci fazda neyin gerçekten gerekli olduğunu genellikle baştaki listeden daha doğru gösteriyor.
Evet, ancak müşterinin izni olduğu ölçüde. Bazı projelerde müşterilerimiz iç sistemlerinin görsellerinin paylaşılmasını istemiyor; bu durumda proje anlatımını marka adı ve ekran görüntüsü olmadan, yapılan işin niteliği üzerinden yapıyoruz. Portföyümüzdeki jenerik anlatımların bir kısmının nedeni budur.
Görüşme sırasında sizin sektörünüze en yakın işi ekran üzerinden gösterebiliyoruz. Bu, bir örnek dosyasına bakmaktan daha yararlı oluyor: hangi kararı neden verdiğimizi, hangi noktada zorlandığımızı ve neyi farklı yapardık sorusunu birlikte konuşabiliyoruz.
Referans görüşmesi de yapabiliyoruz. Benzer ölçekte bir müşterimizle konuşmak isterseniz, ilgili müşteriden izin alıp sizi doğrudan bağlıyoruz. Bunu bir satış aracı olarak değil, karar vermenizi kolaylaştıran bir adım olarak görüyoruz.
Hata yapıyoruz. Bir tahminimiz tutmuyor, bir entegrasyon beklediğimizden uzun sürüyor, bir teste rağmen kaçan bir sorun canlıda ortaya çıkıyor. Bu durumlarda izlediğimiz yol basit: önce bildiriyoruz, sonra düzeltiyoruz, sonra tekrarını önleyecek adımı atıyoruz.
Bildirimi geciktirmemeye özellikle dikkat ediyoruz. Kötü haberin geç verilmesi, haberin kendisinden daha fazla zarar veriyor; çünkü müşterinin elinden seçenek üretme imkânını alıyor. Bir riski fark ettiğimiz gün paylaşmak, o riski birlikte yönetilebilir hâle getiriyor.
Bizden kaynaklanan gecikmelerde telafi planını da birlikte sunuyoruz. Bu genellikle kapsamın önceliklendirilmesi anlamına geliyor: kritik akış zamanında yayına alınıyor, ikincil ekranlar birkaç hafta sonra ekleniyor. Maliyeti müşteriye yansıtmıyoruz.
Evet, her proje yazılı sözleşmeyle başlıyor. Sözleşmede kapsam dokümanına atıf yapılıyor, ödeme planı, teslim takvimi, fikri mülkiyet hakları, gizlilik yükümlülükleri ve garanti süresi tanımlanıyor. Sözleşmeyi imzalamadan önce okumanız ve sormanız için süre bırakıyoruz; anlaşılmayan maddeleri sadeleştirmekten çekinmiyoruz.
Bakım ve aylık çalışma modellerinde ayrı bir hizmet sözleşmesi düzenleniyor. Burada aylık kapsam, çalışma saati, müdahale süreleri ve fesih koşulları yer alıyor. Fesih koşullarını özellikle net yazıyoruz: ayrılmak istediğinizde ne olacağının belirsiz kalması, ilişkinin en gerilimli anına denk geliyor.
