Yazılım yaptırmak istiyorum: ilk görüşme öncesi brief şablonu

"Yazılım yaptırmak istiyorum" noktasına geldiyseniz ilk görüşmeden önce tek sayfalık bir brief yazın. Brief şu on başlığı kapsar: çözmek istediğiniz problem, sistemi kimin kullanacağı, işin bugün nasıl yürüdüğü, olmazsa olmazlar, bağlanacak sistemler, verinin kimin adına tutulacağı, kendi bütçe aralığınız, tarih ve gerekçesi, kimin karar verip test edeceği ve başarının ölçüsü. Aynı belgeyi her firmaya gönderdiğinizde teklifler aynı işe verilmiş olur.

Bu yazıyı, bir yazılım firmasıyla ilk kez konuşmaya hazırlanan kurucular ve işletme sahipleri için yazdım. Benim gözümde ilk görüşmenin en pahalı hâli, iki tarafın da kafasındaki projeyi anlattığı ama kimsenin aynı şeyi anlamadığı görüşmedir. O görüşmeden çıkan teklifler birbirine benzemez, çünkü her firma boşlukları kendi varsayımıyla doldurur. Brief bu boşlukları sizin cevaplarınızla doldurur; mimariyi, teknoloji seçimini ve ekranları firmaya bırakır, yalnızca sizin bilebileceğiniz kararları yazıya döker. Şablonu doldurmak uzun bir iş değil ve bence bir projede harcanacak en verimli birkaç saat bu belgeye gider.

Yazılım yaptırmak için ne gerekir?

Yazılım yaptırmak için teknik bilgi gerekmez; gereken, işinizle ilgili birkaç kararı önceden vermiş olmaktır. Firmalar teknolojiyi, mimariyi ve ekran tasarımını sizden iyi bilir, ama sipariş ekibinizin hangi adımda zaman kaybettiğini, hangi müşterinizin hangi istisnayla çalıştığını ya da projenin neden belirli bir tarihe yetişmesi gerektiğini bilemez. Bence ilk görüşmeye bu soruların cevaplarıyla gelen bir müşteriyle iş çok daha hızlı ilerler. İşi üçe ayırmak yardımcı olur: bazı başlıkları yalnızca siz yazabilirsiniz, bazılarını firmanın size getirmesi gerekir, bir kısmı da birlikte netleşir.

• Sizin getirmeniz gerekenler: problem, kullanıcılar, bugünkü süreç, öncelikler, mevcut sistemlerin listesi, veri ve sahiplik beklentisi, bütçe aralığı, tarih ve gerekçesi, karar verici ve başarı ölçüsü.
• Firmanın getirmesi gerekenler: teknik mimari, platform ve teknoloji önerisi, ekran akışları, iş kırılımı, riskler ve varsayımlar, yazılı kapsam ve fiyat.
• Birlikte netleşecekler: ilk sürümün sınırı, entegrasyonların derinliği, test ve yayın planı.

Bu listeye bakınca akla gelen ilk soru büyük ihtimalle şu: "ekranları da çizmeli miyim?" Bence gerek yok; elinizde bir taslak varsa ekleyin, ama ekranlar brief'in değil keşif aşamasının çıktısıdır. Ekran çizmeye başladığınızda çoğu zaman problemi değil bir çözümü tarif etmiş olursunuz ve firmanın daha basit bir yol önermesinin önünü kapatırsınız.

Tek sayfalık yazılım brief şablonu: on başlık

Yazılım brief'i, bir yazılım firmasıyla ilk görüşmeden önce hazırlanan ve problemi, kullanıcıları, öncelikleri, bütçe aralığını ve tarihi anlatan tek sayfalık belgedir. Aşağıdaki tablo, ilk görüşmeden önce doldurmanızı önerdiğim on başlığı ve her birinin firmaya ne kazandırdığını gösteriyor. Her başlığa iki üç cümle yetiyor; belge bir sayfayı aşıyorsa ya fazla ayrıntıya giriyorsunuzdur ya da aslında iki ayrı proje anlatıyorsunuzdur. Şablonu bilerek kısa tutuyorum, çünkü uzun bir belgeyi kimse sonuna kadar okumaz ve önemli bir karar ayrıntıların arasında kaybolur.

Problem, kullanıcılar ve bugünkü süreç

Problemi yazarken bir çözüm adı kullanmamaya çalışın. "Bir mobil uygulama istiyoruz" bir çözümdür; "sahadaki ekip müşteriden aldığı imzalı formu ofise akşam getiriyor ve fatura iki gün gecikiyor" bir problemdir. İkinci cümle firmaya hem neyi çözeceğini hem de başarının neye benzeyeceğini söyler ve belki en ucuz çözümün bir mobil uygulama değil, basit bir web formu olduğunu gösterir. Kullanıcıları yazarken unvan değil rol düşünün: siparişi giren, onaylayan, sevk eden ve raporu okuyan aynı kişi değilse bunlar ayrı ekranlar ve ayrı yetkiler demektir. Bugünkü süreç için en iyi kanıt, şu an kullandığınız tablonun, formun ya da mesaj akışının ekran görüntüsüdür; işin bir tabloda yürüdüğü durumlarda panelin hangi noktada gerektiğini Excel'den yazılıma geçiş yazımızda ayrıca anlattık.

Olmazsa olmazlar ve sonraya kalabilecekler

Olmazsa olmazları sonraya kalabileceklerden ayırmak, fiyatı ve süreyi en çok belirleyen karardır; bence brief'in en zor kısmı da budur. Her şeyi olmazsa olmaz diye işaretlemek çok doğal bir tepki, ama o zaman firma her şeyi ilk sürüme koyar ve fiyatla süre birlikte şişer. Kendinize şu soruyu sormanızı öneririm: bu özellik ilk gün yoksa işinizi yine de yapabilir misiniz? Cevap evetse o özellik ikinci listeye gider. İkinci liste unutulmuş istekler listesi değildir; teklifte ayrı bir kalem olarak görmek istediğiniz işlerdir. Kapsamı daraltma yöntemini MVP geliştirme yazımızda daha ayrıntılı ele aldık.

Entegrasyonlar: mevcut sistemleriniz

Entegrasyon, tekliflerin en çok ayrıştığı yerdir, çünkü bir firma "muhasebe programına bağlanır" cümlesini tek yönlü bir dosya aktarımı, bir diğeri iki yönlü canlı bir eşleşme olarak okuyabilir. Brief'e her sistem için üç bilgi yazın: sistemin adı ve sürümü, hangi verinin hangi yöne akacağı ve o sisteme teknik erişimi kimin verebileceği. Sistemin bir API'si, yani başka yazılımların ona bağlanmasını sağlayan bir arayüzü olup olmadığını bilmiyorsanız sorun değil; bilmediğinizi yazmanız yeter. Ben özel yazılımın en güçlü tarafını burada görüyorum: ekibinizin alıştığı muhasebe ya da CRM düzenini bırakmadan, onlarla konuşan bir sistem kurabilirsiniz. Bedeli de burada ortaya çıkar, çünkü her entegrasyon test edilmesi ve bakımı yapılması gereken bir parçadır; listeyi gerçekten kullanılacak bağlantılarla sınırlı tutun.

Bütçe aralığı ve tarih

Bütçeyi saklamak, bence ilk görüşmenin en pahalı refleksi. Bütçeyi bilmeyen bir firma ya en geniş çözümü fiyatlar ya da sizi ikinci bir tura zorlar; aralığı bilen firma ise kapsamı o aralığa göre kurar ve neyin dışarıda kaldığını açıkça söyler. Buraya yazılacak rakam bir piyasa ortalaması değil, sizin harcamaya hazır olduğunuz aralıktır; fiyatın neye göre değiştiğini yazılım yaptırma maliyeti yazımızda ayrıca ele aldık. Tarihin yanına mutlaka gerekçesini yazın: bir fuar, bir sezon başlangıcı ya da bir sözleşmenin bitişi farklı esneklikler taşır ve firmanın neyi önce teslim edeceğini belirler. Projeyi bir destek programıyla finanse etmeyi düşünüyorsanız bunu da yazın, çünkü programın koşulları kapsamı ve teslim kalemlerini etkileyebilir; bu konuyu KOBİ dijital dönüşüm destekleri yazımızda anlattık.

Kim karar verir, kim test eder, başarı neye benzer?

Projeyi firmayla kimin yürüteceğini ve son kararı kimin vereceğini yazın; bu iki kişi aynı değilse ikisinin de ilk görüşmede bulunması işleri hızlandırır. Test eden kişi sistemi gerçekten kullanacak ekipten gelmeli ve düzenli aralıklarla çalışan bir sürümü deneyip geri bildirim verecek zamanı olmalı. Başarı ölçüsü olarak ölçülebilir ve sizin kontrolünüzdeki bir şey seçin: siparişin girildiği andan sevk edildiği ana kadar geçen süre, ay sonu raporunun ne kadar sürede hazırlandığı ya da müşterinin telefon etmeden sipariş durumunu görebilmesi gibi. Başarı tanımı olmayan bir projede kabul aşaması çoğu zaman tartışmalı geçer; ölçüt baştan yazılıysa "bitti mi" sorusunun cevabı da yazılıdır.

Veri, kaynak kod ve hesaplar kimin adına olacak?

Brief'e verinin, kaynak kodun ve hesapların kimin adına olacağını baştan yazın; sözleşmeye kalmış bir ayrıntı gibi görünse de projenin sonunda neyin size ait olduğunu bu karar belirler. Ekim 2026 itibarıyla 6698 sayılı Kişisel Verilerin Korunması Kanunu'nun 3. maddesi, kişisel verilerin işleme amaçlarını ve vasıtalarını belirleyen kişiyi veri sorumlusu, onun verdiği yetkiyle onun adına veri işleyen kişiyi de veri işleyen olarak tanımlıyor. Aynı Kanunun 12. maddesi, kişisel verilerin sizin adınıza başka biri tarafından işlenmesi hâlinde güvenlik tedbirlerinden o kişiyle birlikte sorumlu olduğunuzu söylüyor (6698 sayılı Kanun, mevzuat.gov.tr (yeni sekmede açılır)). Müşteri ya da çalışan verisi tutan bir sistemde bu yüzden brief'e hangi kişisel verilerin tutulacağını ve verinin nerede barındırılmasını beklediğinizi yazmanızı öneririm; firma barındırma ve erişim kararlarını ancak bunu bilirse baştan doğru kurar.

Kaynak kodun size ait olması da sözleşmenin nasıl yazıldığına bağlıdır. Ekim 2026 itibarıyla 5846 sayılı Fikir ve Sanat Eserleri Kanunu bilgisayar programlarını eser olarak sayıyor (madde 2) ve mali hakları kullanma yetkisini eser sahibine veriyor (madde 18). Aynı Kanun, mali haklara dair sözleşmelerin yazılı olmasını ve konusu olan hakların ayrı ayrı gösterilmesini şart koşuyor (madde 52) (5846 sayılı Kanun, mevzuat.gov.tr (yeni sekmede açılır)). Benim buradan çıkardığım pratik sonuç şu: kodun size devredileceğini sözlü bir anlayışa bırakmayın, beklentinizi brief'e yazın ve sözleşmede hakların tek tek sayıldığını kontrol edin. Bu bir hukuki görüş değil; sözleşmenizi imzalamadan önce bir avukata okutmanızı öneririm.

UlvionTech'te kod deposu, bulut hesapları, alan adları ve üçüncü taraf servisler ilk günden müşterinin şirketi adına açılıyor ve bunu sözleşmeye giren bir madde olarak yazıyoruz. Özel yazılımın abonelikli bir hazır programdan en somut farkını ben burada görüyorum: hazır programda veriniz ve kurallarınız sağlayıcının sisteminde yaşar, özel yazılımda kod, sunucu ve alan adı sizin adınızadır. Bunun bir bedeli de var: sistemi kimin barındıracağı, güncelleyeceği ve yedekleyeceği sorusunun sizin tarafınızda bir sahibi olmalı. Brief'e bu kişiyi de yazın; güncelleme ve yedekleme takvimi o kişiyle kurulur.

Brief'iniz hazır programa mı, özel yazılıma mı işaret ediyor?

Brief'i doldurduğunuzda cevap çoğu zaman kendiliğinden belirir: problem sektördeki herkesin yaşadığı standart bir işse hazır bir program yetebilir, kurallarınız size özgüyse ve mevcut sistemlerinize bağlanmanız gerekiyorsa özel yazılım daha mantıklı hâle gelir. Bu soruyu ilk görüşmeden önce kendinize sormanızı öneririm, çünkü bir yazılım firmasının bu soruya tamamen tarafsız cevap vermesi kolay değil; biz de bu yüzden aşağıdaki tabloya hazır programın önde olduğu satırı da koyuyoruz. Tablo, brief'teki başlıkların iki seçenekte nasıl karşılandığını gösteriyor. Konunun tamamını özel yazılım mı hazır yazılım mı yazımızda ele aldık.

• Hazır program yeterlidir, eğer: süreciniz sektörünüzde standartsa, entegrasyon ihtiyacınız sağlayıcının sunduğu bağlantılarla karşılanıyorsa ve birkaç hafta içinde kullanmaya başlamanız gerekiyorsa.
• Özel yazılım daha mantıklıdır, eğer: kurallarınız sizi rakiplerinizden ayıran şeyse, verinin nerede durduğu sizin için önemliyse, kullanıcı ya da şube sayınız büyüdükçe maliyetin de büyümesini istemiyorsanız ve mevcut sistemlerinize bağlanmanız gerekiyorsa.
• Arada bir yol da var: hazır bir çekirdek ve onun etrafında özel bir katman; brief'teki entegrasyon listesi bu yolun mümkün olup olmadığını gösterir.

Özel yazılımın ilk yatırımı hâlâ daha yüksek ve bunu saklamak istemem. Öte yandan yapay zekâ destekli geliştirme araçları tekrarlayan kodun yazılmasını hızlandırıyor ve bence bu, özel yazılımın yapım maliyetini aşağı çeken bir etken; bu yüzden birkaç yıl önce yapılmış maliyet karşılaştırmalarını bugün olduğu gibi kullanmamak gerektiğini düşünüyorum. Hesabı kendi rakamlarınızla yapın: hazır programın üç ila beş yıllık toplam abonelik maliyetini, özel yazılımın ilk yapım ve yıllık bakım maliyetiyle yan yana koyun. Bu karşılaştırmayı brief olmadan yapmaya çalışmam, çünkü kullanıcı sayısını, şube planını ve entegrasyon listesini bilmeden iki tarafın da maliyeti tahmin olarak kalır.

Doldurulmuş bir örnek: varsayımsal bir toptancının bayi sipariş brief'i

Şablonun nasıl dolduğunu göstermek için uydurma ama gerçekçi bir senaryo kullanacağım; bu bir müşteri hikâyesi değil, yalnızca bir örnek. Varsayalım ki bayilerine ürün satan bir toptancı var. Bayiler siparişlerini telefonla ve mesajla veriyor, ofis ekibi bunları her gün ortak bir tabloya geçiriyor ve muhasebe programına ayrıca fatura giriyor. Şirket sahibi, bayilerin siparişlerini kendilerinin girebileceği bir sistem istiyor. Bu varsayımlarla brief şöyle görünebilir:

1. Problem: Siparişler telefon ve mesajla geliyor ve elle tabloya geçiriliyor; yanlış ürün ve eksik adet sevk edilebiliyor, bayiler sipariş durumunu öğrenmek için ofisi arıyor.
2. Kullanıcılar: bayiler sipariş verir ve durumu görür, ofis ekibi onaylar, depo hazırlar ve sevk eder, şirket sahibi raporları okur.
3. Bugünkü süreç: telefon ve mesaj, ortak bir tablo, muhasebe programında elle fatura; tablonun ekran görüntüsü ekte.
4. Öncelikler: ilk gün bayinin kendi fiyat listesiyle sipariş vermesi, ofisin onayı, deponun hazırlık listesi ve bayinin durum görmesi; mobil uygulama, kampanya modülü ve ayrıntılı raporlar sonraya kalabilir.
5. Entegrasyonlar: onaylanan siparişin muhasebe programına fatura taslağı olarak aktarılması; programın API'si olup olmadığı bilinmiyor, muhasebe tarafındaki yetkilinin iletişim bilgisi ekte.
6. Veri ve sahiplik: bayi firma bilgileri ve yetkililerin iletişim bilgileri tutulacak; barındırma yeri firmayla birlikte kararlaştırılacak, kod deposu ve sunucu şirket adına açılacak.
7. Bütçe aralığı: şirketin kendi belirlediği aralık; bu satıra sizin rakamınız gelir.
8. Tarih ve gerekçesi: yeni sezon fiyat listesinin bayilere açıklanacağı tarih; o tarihte en azından sipariş girişi çalışmalı.
9. Karar ve test: kararı şirket sahibi verir; testi ofis ekibinden bir kişi ve gönüllü birkaç bayi yapar.
10. Başarı ölçüsü: telefonla gelen siparişlerin azalması ve ofisin günlük tablo girişini bırakması.

Bu brief'te teknik tek bir kelime olmadığına dikkat edin; yine de bir firmanın web tabanlı bir bayi portalını, bir onay akışını ve bir muhasebe aktarımını fiyatlaması için yeterli bilgi taşıyor. Mobil uygulamayı bilerek sonraya kalabilecekler arasına koydum, çünkü bayiler siparişi çoğunlukla masa başında veriyorsa ilk sürüm için mobil uyumlu bir web uygulaması yeterlidir. Bu ayrımın ölçütlerini mobil uygulama mı web uygulaması mı yazımızda tartıştık. Örnekteki en riskli satır entegrasyon satırıdır; muhasebe programının bağlantı imkânı belli olmadan verilen her fiyat bir varsayım içerir ve bunu teklifte açıkça görmek istersiniz.

Uygulama yaptırmak istiyorum: mobil projede brief'e eklenecekler

Mobil uygulama yaptırmak istiyorsanız şablondaki on başlık aynen geçerli, ama brief'e birkaç ek bilgi koymanızı öneririm. Mobil projelerde kolayca atlanan bir konu, uygulama mağazası hesaplarının kimin adına açılacağıdır, çünkü bu soru kolayca yayın haftasına kalabilir. Ekim 2026 itibarıyla Apple, geliştirici programına kurum olarak katılmak için sözleşme yapabilen bir tüzel kişilik ve D-U-N-S numarası istiyor (Apple Developer Program (yeni sekmede açılır)). Google Play de kurum hesabı için D-U-N-S numarasını zorunlu tutuyor (Google Play Console Yardım (yeni sekmede açılır)). Bu numara projenin içinde değil, şirketiniz adına yürüyen ayrı bir işlem olduğu için brief'e numaranızın olup olmadığını yazın. Hesaplar sizin adınıza açıldığında uygulama da mağazada sizin adınızla yayımlanır.

• Platformlar: iOS, Android ya da ikisi; kullanıcılarınızın hangi cihazları kullandığını biliyorsanız yazın.
• Çevrimdışı kullanım: sahada internetsiz çalışılıp çalışılmayacağı ve verinin sonradan eşitlenip eşitlenmeyeceği.
• Bildirimler ve cihaz özellikleri: anlık bildirim, kamera, konum ya da barkod okuma gibi ihtiyaçlar.
• Mağaza hesapları: Apple ve Google hesaplarının hangi tüzel kişi adına açılacağı ve D-U-N-S numarasının durumu.

"Uygulama yaptırmak istiyorum" diye başlayan projelerin önemli bir kısmında ilk sürüm için mobil uyumlu bir web uygulamasının yettiğini düşünüyorum; bu yol ilk aşamada hem mağaza onayını hem de iki ayrı platformu ortadan kaldırır. Brief'te bu soruyu açık bırakmanızı, yani "mobil uygulama mı web mi, bilmiyoruz" diye yazmanızı öneririm; firmanın gerekçeli bir öneri getirmesi, sizin çözümü önceden kilitlemenizden daha değerlidir. Mobil projeleri mobil uygulama geliştirme hizmetimiz altında, abonelikle satılacak ürünleri ise SaaS platformu hizmetimiz altında yürütüyoruz.

İlk görüşmeye götürmeniz gerekenler: kontrol listesi

İlk görüşmeye brief'in yanında birkaç somut kanıt götürmek, görüşmeyi tahmin yürütmekten çıkarıp gerçek bir çalışma toplantısına çevirir. Aşağıdaki liste sizin hazırlayıp götürmeniz gerekenlerdir; firmaya sorulacak soruları ve teklifleri okuma yöntemini yukarıda bağlantısını verdiğimiz maliyet yazısında ayrıca listeledik. Ben listedeki örnek veri maddesini özellikle önemsiyorum, çünkü gerçek bir kayıt, uzun bir sözlü anlatımın atladığı alanları ve istisnaları hemen gösterir.

1. Tek sayfalık brief, tüm firmalara aynı sürümüyle gönderilmiş hâlde.
2. Bugünkü sürecin kanıtları: kullandığınız tablonun, formun ya da mesaj akışının ekran görüntüleri.
3. Kişisel veriden arındırılmış örnek veri: birkaç satır sipariş, müşteri ya da ürün kaydı; gerçek isim, telefon ve e-posta olmadan.
4. Bağlanacak sistemlerin listesi ve her biri için teknik erişimi verebilecek kişinin adı.
5. Beğendiğiniz ya da sorun yaşadığınız ekran örnekleri, nedenini anlatan birer cümleyle.
6. Bütçe aralığınız ve tarihinizin gerekçesi.
7. Karar vericinin takvimi; mümkünse görüşmeye kendisinin katılması.
8. Görüşmeden sonra yazılı bir özet isteyeceğinizi baştan söylemek.

UlvionTech'te keşif görüşmesi 30 ile 45 dakika sürüyor ve problemi nasıl anladığımızın yazılı bir özetiyle bitiyor; ardından kapsam dokümanı, teslim planı ve sabit fiyat geliyor. Elinizde brief olduğunda bu görüşmeyi sizin tarafınızdaki boşlukları doldurmak yerine bizim tarafımızdaki soruları sormak için kullanabiliyoruz ve ikinci tür görüşme iki taraf için de çok daha verimlidir. Yazılı kapsam olmadan verilen sabit fiyata temkinli bakıyorum; brief, kapsamın yazıya dökülmesini ve fiyatın o kapsama bağlanmasını mümkün kılan ilk belgedir.

Brief hazırlarken sık yapılan hatalar

Brief hazırlarken en sık görülen hata, problem yerine bir çözümü tarif etmektir. Aşağıdaki hatalar belli bir müşteriye ait değil, brief hazırlığında sık görülen genel kalıplar. Ben çoğunun aynı kökten geldiğini düşünüyorum: brief'i firmayı ikna etmek için hazırlanmış bir sunum gibi yazmak. Oysa brief'in tek görevi, sizin kararlarınızı firmaya eksiksiz ve değişmeden aktarmaktır.

• Problem yerine çözüm yazmak: başka bir uygulamanın ekranlarını tarif edip aynısını istemek, firmanın daha basit bir yol önermesini engeller.
• Her şeyi olmazsa olmaz saymak: ilk sürüm şişer, fiyat ve süre birlikte büyür, teklifleri karşılaştırmak da zorlaşır.
• Bütçeyi saklamak: firma ya en geniş çözümü fiyatlar ya da kapsamı kendi tahminine göre kırpar.
• Gerekçesiz tarih: "bir an önce" bir tarih değildir; gerekçe yoksa neyin önce teslim edileceği de belirlenemez.
• Her firmaya farklı brief göndermek: görüşmeden görüşmeye eklenen istekler, tekliflerin farklı işlere verilmesine yol açar.
• Gerçek kişisel veri paylaşmak: örnek dosyada müşteri adları, telefonlar ya da kimlik bilgileri bulunmamalı.
• Yayından sonrasını yazmamak: sistemi kimin yöneteceği ve bakımın nasıl yürüyeceği brief'te yoksa teklifte de eksik kalır.

Bu listede en çok önemsediğim madde her firmaya aynı brief'i göndermek. Görüşmelerde yeni fikirlerin çıkması doğal; benim önerim bu fikirleri brief'in yeni bir sürümüne yazıp tüm firmalara aynı anda göndermeniz. Böylece elinize gelen teklifler gerçekten aynı işe verilmiş olur ve aradaki farkı fiyatla birlikte yaklaşımda da görürsünüz.

Biz olsak ne yapardık?

Ben olsam ilk görüşmeden önce birkaç saat ayırıp şablonu doldururdum ve sistemi gerçekten kullanacak iki üç kişiyle kısa konuşmalar yapardım. Kullanıcıların söylediği tek bir cümle, çoğu zaman bir özelliği olmazsa olmazlardan sonraya kalabileceklere taşır ya da tam tersini yapar. Ardından aynı brief'i en fazla üç firmaya gönderirdim; daha fazlası karşılaştırmayı zorlaştırır ve her görüşme sizin zamanınızdan gider. Her firmadan yazılı bir özet, yazılı bir kapsam ve o kapsama bağlı bir fiyat isterdim; özeti olmayan bir teklifi, firmanın beni anlayıp anlamadığını ölçemeyeceğim için ciddiye almazdım.

UlvionTech'in İstanbul'daki ekibinde çalışma şeklimiz de bu sırayı izliyor: keşif görüşmesi, yazılı kapsam ve sabit fiyat, ardından iki haftalık döngülerle ilerleyen ve her döngüde test ortamında açıp deneyebileceğiniz çalışan bir sürüm. Kapsam sonradan değişirse değişiklik geliştirilmeden önce fiyatlanıyor; kod deposu, hesaplar ve alan adları ilk günden sizin adınıza açılıyor. Projenizin büyük kısmı tarayıcıda çalışan bir sistemse onu web uygulaması geliştirme kapsamında, sizin brief'iniz üzerinden ele alırız.

Hangi durumlarda bizimle çalışmamalısınız?

Brief'i doldurduktan sonra bir yazılım firmasına hiç ihtiyacınız olmadığını görebilirsiniz ve bence bu da iyi bir sonuçtur. Aşağıdaki durumlarda size başka bir yol öneririm; ilk görüşmede de aynısını söylerim.

• Kapsam çok küçükse: tek bir form, tek sayfalık bir duyuru ya da birkaç kişinin kullandığı basit bir liste için özel yazılım yaptırmak gereksiz bir yatırımdır.
• Hazır bir program işinizi görüyorsa: süreciniz standartsa ve kurallarınıza uyan bir hazır program varsa onu kullanın; ilk yatırımı ve süreyi kısaltır.
• Şirket içinde bir yazılım ekibiniz varsa: brief'i önce onlarla paylaşın; dışarıdan bir firma, ekibin kapasitesi yetmediğinde ya da belirli bir uzmanlık gerektiğinde mantıklıdır.
• Fikri henüz sınamadıysanız: kimsenin kullanıp kullanmayacağını bilmediğiniz bir fikir için önce bir prototip ya da yapay zekâ ile kurulmuş hızlı bir deneme daha az risklidir.
• Sistemi kimse sahiplenmeyecekse: yayından sonra test edecek, karar verecek ve kullanıcıları yönlendirecek biri yoksa en iyi yazılım da kullanılmadan kalır.

Bu durumların hiçbiri sizi tarif etmiyorsa ve şablonu doldurduysanız, belgeyi iletişim formumuzdan gönderebilirsiniz; keşif görüşmesine brief'te boş kalan başlıklardan başlarız.