Web uygulaması nedir? Web sitesinden farkı, ne zaman gerekir?

Web uygulaması, tarayıcıda açılan ama okunmak için değil kullanılmak için yapılmış bir yazılımdır: kullanıcı giriş yapar, kayıt oluşturur, veriyi değiştirir ve sistem ona göre yanıt verir. Web sitesi ise okunmak için yapılır. Ayrımı teknoloji değil, ziyaretçinin ne yaptığı belirler: okuyorsa site, giriş yapıp veri değiştiriyorsa uygulama.

Bu yazıyı, "bize bir site mi lazım, uygulama mı?" sorusuyla teklif istemeye hazırlanan işletme sahipleri ve operasyon sorumluları için yazdım. Bir yazılım ekibinde çalıştığım için web uygulamasını savunmam beklenir; bu yüzden basit bir sitenin yettiği durumları da ayrı bir bölümde yazdım. Benim için ilk soru, kullanıcının ekranda ne yapacağıdır; hangi teknolojinin kullanılacağı bu cevaptan sonra konuşulur.

Web uygulaması nedir?

Web uygulaması, kullanıcının tarayıcı üzerinden kullandığı, sunucuda çalışan bir yazılım ve ona bağlı bir veritabanından oluşan sistemdir. Cihaza kurulum gerekmez; adresi açmak yeterlidir ve güncellemeler sunucuda yapıldığı için kullanıcılara aynı anda ulaşır. "Web app" ve "web tabanlı uygulama" da aynı şeyi anlatır. Siparişlerinizi takip ettiğiniz bir müşteri paneli, çalışanların izin talebi girdiği bir şirket içi ekran ya da randevu alınan bir sistem web uygulamasıdır.

Bana göre bir web uygulamasını web sitesinden ayıran asıl özellik, kullanıcıya göre değişen veridir. Bir ekran kim baktığına göre farklı bir şey gösteriyorsa ve kullanıcı oradan veri ekleyip değiştirebiliyorsa, artık bir uygulama tasarlıyorsunuz demektir. Bu çizgiyi geçtiğiniz anda hesaplar, yetkiler, yedekler ve bakım da işin içine girer. Bütçe ve süre konuşması da bu noktada değişir.

Web uygulaması nasıl çalışır?

Bir web uygulaması dört parçayla çalışır: tarayıcıda görünen arayüz, sunucudaki iş kuralları, verinin tutulduğu veritabanı ve kullanıcıyı tanıyan oturum. Parçaların görevleri şöyledir:

• Ön yüz (frontend). Tarayıcıda gördüğünüz ekranlar, formlar ve butonlar. HTML, CSS ve JavaScript ile yazılır.
• Arka uç (backend). Sunucuda çalışan ve "bu kullanıcı bu kaydı görebilir mi, bu sipariş onaylanabilir mi" gibi kuralları uygulayan kısım. Ön yüzle bir API üzerinden konuşur; API kavramını API nedir yazısında ayrıntılı anlattım.
• Veritabanı. Kullanıcıları, kayıtları ve işlem geçmişini tutan yer. Uygulamanın asıl değeri büyük ölçüde burada biriken veridir.
• Oturum. Giriş yaptıktan sonra sistemin sizi tanımasını sağlayan mekanizma. Her ekranda şifre sormamasının nedeni budur.

Oturum, bir web uygulamasının temel teknik parçasıdır. MDN'nin HTTP çerezleri sayfasına (yeni sekmede açılır) göre HTTP protokolü varsayılan olarak durumsuzdur (stateless); çerezler, web uygulamalarının sınırlı miktarda veri saklamasını ve durum bilgisini hatırlamasını sağlar. Giriş bilgileriniz doğruysa sunucu, oturum kimliği içeren bir çerez gönderir ve sonraki isteklerde sizi bu çerezle tanır.

Tek sayfa uygulaması (SPA), bir web uygulaması yapısıdır: MDN'nin SPA tanımına (yeni sekmede açılır) göre bu yapıda tarayıcı tek bir belge yükler ve içerik değiştikçe sayfanın gövdesini JavaScript ile günceller.

Web uygulamasının mimarisi, bence yazılım ekibinin vermesi gereken bir karardır. İşletmenin bilmesi gereken, uygulamanın ön yüz, arka uç, veritabanı ve oturum parçalarının yayından sonra da birinin bakımına ihtiyaç duyduğudur.

Web uygulaması ile web sitesi arasındaki fark nedir?

Web uygulaması ile web sitesi arasındaki temel fark, ziyaretçinin ne yaptığıdır: web sitesinde okur, inceler ve iletişime geçer; web uygulamasında giriş yapar, kayıt oluşturur ve veriyi değiştirir. İkisi de tarayıcıda açılır, ikisi de aynı dillerle yazılabilir. Bu yüzden teknolojiye bakarak ayırt etmek zordur. Kullanıcının ekranda geçirdiği beş dakikaya bakmak çok daha kolaydır.

Web sitesi ile web uygulaması; ziyaretçinin yaptığı iş, hesap, roller, veri, ödeme, arama görünürlüğü, bakım ve maliyeti büyüten kalemlerde ayrılır:

Site ile uygulama arasındaki sınır her zaman keskin değildir. İçerik yönetim paneli olan siteler, ziyaretçinin gözünden hâlâ web sitesidir: geliştirdiğimiz estetik cerrahi grubu sitesinde sayfalar bir içerik yönetim panelinden güncelleniyor. Editörler panele giriş yapıyor, ziyaretçi ise hiçbir yere giriş yapmadan sayfaları okuyor.

Giriş istemeyen hesaplama araçları da site ile uygulama arasında bir gri bölgedir. Geliştirdiğimiz astroloji hesaplayıcıları platformunda kullanıcı doğum bilgilerini girip sonuç alıyor, ama üyelik gerekmiyor. Ekranda hesaplama yapılır, fakat kullanıcıya ait kalıcı bir hesap tutulmaz.

Site ile uygulama arasındaki gri bölgede kararı tek bir soruyla vermenizi öneririm: kullanıcının girdiği veri, oturum kapandıktan sonra da saklanıp ona geri gösterilecek mi? Cevap evetse hesap, yetki ve kişisel veri sorumluluğu başlar; bir uygulama planlıyorsunuz demektir. Kurumsal site tarafını ayrıntılı incelemek isterseniz kurumsal web sitesi yaptırma rehberine bakabilirsiniz.

Web uygulaması örnekleri nelerdir?

Gündelik hayattaki web uygulaması örnekleri internet bankacılığı, e-Devlet gibi giriş yapılan kamu hizmetleri ve tarayıcıdan kullanılan e-posta ile belge düzenleme araçlarıdır. İşletmeler için en sık türler müşteri portalı, randevu sistemi, şirket içi panel, SaaS ürünü ve e-ticarettir; her biri kendi kurallarıyla ayrı bir proje olarak ele alınır:

• Müşteri ve bayi portalı. Müşterinin siparişlerini, faturalarını ve bakiyesini gördüğü alan. Bayiye özel fiyat ve sipariş akışını B2B portal nedir yazısı ayrıntılı ele alıyor.
• Randevu ve rezervasyon sistemi. Müşterinin boş saat seçtiği, işletmenin takvimi yönettiği yapı. Klinikler için adımlar online randevu sistemi rehberinde anlatılıyor.
• Şirket içi panel ve operasyon aracı. Stok, iş emri, izin veya teklif gibi Excel'e dağılmış takibin tek ekranda toplanması. Geçişin ne zaman mantıklı olduğunu Excel'den yazılıma geçiş yazısı tartışıyor.
• SaaS ürünü. Birden çok şirkete abonelikle satılan yazılım; her müşterinin verisi diğerinden ayrı tutulur. Fikirden ilk müşteriye giden yolu SaaS nasıl yapılır rehberi anlatıyor.
• E-ticaret ve sipariş sistemi. Vitrin kısmı bir site gibi okunur; sepet, ödeme, sipariş geçmişi ve müşteri hesabı ise uygulama gibi çalışır. Maliyet kalemleri e-ticaret sitesi kurma maliyeti yazısında.

Web uygulaması örneklerinin ortak noktası, her birinin arkasında birilerinin her gün değiştirdiği bir veri olmasıdır. Bir web uygulamasının değerini ekranların güzelliğinden çok, o verinin doğru, güncel ve yalnızca yetkili kişilerce görülebilir olması belirler. Ekran tasarımını öne alıp veri modelini sona bırakmak, pahalıya patlayabilen bir sıralama hatasıdır. Ben veri modelinin ve rollerin ilk tasarım taslağından önce yazıya dökülmesini tercih ederim.

Hesaplar, roller ve yetkiler web uygulamasında neden önemlidir?

Hesaplar, roller ve yetkiler, bir web uygulamasında kimin neyi görebileceğini ve değiştirebileceğini belirleyen kurallardır. Web sitesinde neredeyse hiç olmayan bu katman, uygulamanın hem çok emek isteyen hem de riskli kısmıdır.

Ekim 2026 itibarıyla güncel liste olan OWASP Top 10:2025 (yeni sekmede açılır), bozuk erişim kontrolünü (Broken Access Control) web uygulaması güvenlik risklerinde birinci sıraya koyuyor; aynı sayfaya göre test edilen uygulamaların %100'ünde bu hatanın bir türü bulunmuş. OWASP'a göre erişim kontrolü, kullanıcıların kendilerine tanınan yetkilerin dışında işlem yapamamasını sağlar. Bu kontrol bozulduğunda sonuç tipik olarak yetkisiz bilgi ifşası, verinin değiştirilmesi ya da silinmesidir.

Rol sayısının bir projede işi nasıl büyüttüğünü bir örnekle düşünelim. Varsayalım ki bir toptancı, bayilerinin sipariş verdiği bir portal istiyor. Bayi yalnızca kendi siparişlerini ve kendisine tanımlı fiyatları görmeli; satış temsilcisi kendi bölgesindeki bayileri görmeli; muhasebe tüm faturaları görüp düzeltebilmeli; yönetici ise kullanıcı ekleyip çıkarabilmeli. Dört rol ve her rol için "görür, ekler, değiştirir, siler" kararları, ekran sayısından daha çok iş çıkarır.

Teklif istemeden önce rolleri kâğıda yazmanın, bir web uygulaması için yapılabilecek en verimli hazırlık olduğunu düşünüyorum: kim var, her biri neyi görür, neyi değiştirir. Rol listesi olmadan iki teklif arasındaki fiyat farkını yorumlamak çok zordur. Kişisel veri işleniyorsa erişim kayıtları ve saklama süreleri de bu katmana girer; yazılım ekibinden isteyeceklerinizi web sitesi KVKK kontrol listesinde bulabilirsiniz. Bu bilgi hukuki görüş değildir; kendi durumunuz için bir avukata danışın.

Ne zaman web sitesi yeter, ne zaman web uygulaması gerekir?

Web sitesi, ziyaretçiye bilgi verip onu bir talebe yönlendirmeniz yettiğinde yeter; web uygulaması ise kullanıcının giriş yapıp kendi verisiyle iş yapması gerektiğinde gerekir. Benim önerdiğim yöntem basit: iki ölçüt listesini yan yana koyun; hangisinde daha çok "evet" diyorsanız ilk adımınız odur.

Web sitesi ne zaman yeterlidir?

Web sitesi; ziyaretçi giriş yapmıyorsa, içeriği yalnızca ekibiniz değiştiriyorsa ve amaç tanıtım ile talep toplamaksa yeterlidir.

• Amaç tanıtım ve talep toplamaksa. Hizmetlerinizi anlatmak, güven vermek ve form, telefon ya da mesajlaşma uygulaması ile iletişim almak istiyorsanız.
• Ziyaretçinin hesabı olmayacaksa. Kimse giriş yapmayacak, kimseye özel bir ekran gösterilmeyecekse.
• İçeriği yalnızca ekibiniz değiştiriyorsa. Yeni sayfa, yazı veya ürün tanıtımını sadece sizin tarafınız ekliyorsa.
• Arama motorundan gelen trafik önceliğinizse. Sayfaların herkese açık olması ve okunması gerekiyorsa.

Web uygulaması ne zaman gerekir?

Web uygulaması; kullanıcılar giriş yapacak, farklı roller farklı veri görecek ve kayıtlar ekrandan girilecekse gerekir.

• Kullanıcı giriş yapacaksa. Müşteri, bayi, çalışan ya da hasta kendi hesabıyla işlem yapacaksa.
• Farklı kişiler farklı şeyler görecekse. Rol ve yetki listeniz en az iki satırdan oluşuyorsa.
• Veriyi kullanıcı değiştirecekse. Sipariş, randevu, talep veya stok hareketi gibi kayıtlar ekrandan girilecekse.
• Bir iş akışı izlenecekse. Onay, durum değişikliği, bildirim ve geçmiş kaydı gerekiyorsa.
• Başka sistemlerle konuşacaksa. Muhasebe, ödeme, kargo veya pazaryeri ile veri alışverişi yapılacaksa.

Hem web sitesi hem web uygulaması ölçütlerine "evet" diyorsanız, cevap ikisinin birlikte olmasıdır: herkese açık bir tanıtım sitesi ve onun bir bölümünde ya da alt alan adında giriş yapılan bir uygulama. Böyle bir durumda ben olsam ikisini aynı planın ama ayrı parçaları olarak ele alırdım. Böylece site hızlıca yayına alınır, uygulama kendi takviminde ilerler ve biri diğerini bekletmez.

Web uygulaması, PWA ve mobil uygulama arasındaki fark nedir?

Web uygulaması tarayıcıda çalışır; PWA (progressive web app) cihaza kurulabilen bir web uygulamasıdır; mobil uygulama ise mağazadan indirilip cihaza kurulan ayrı bir yazılımdır. MDN'nin PWA tanımına (yeni sekmede açılır) göre PWA, web platformu teknolojileriyle yapılan ama platforma özel bir uygulamaya benzer deneyim sunan bir uygulamadır. Bir web sitesi gibi tek kod tabanından birçok cihazda çalışabilir; platforma özel bir uygulama gibi cihaza kurulabilir ve çevrimdışıyken de çalışabilir.

Bir PWA'nın adı ve simgesi gibi bilgileri tarayıcıya bildiren dosyanın kuralları, W3C'nin Ekim 2026 itibarıyla taslak (Working Draft) aşamasındaki Web Application Manifest belirtiminde (yeni sekmede açılır) tanımlanıyor. PWA ve mobil uygulama konusunda benim görüşüm kısa: ihtiyaç tarayıcıda çözülebiliyorsa önce web uygulamasıyla başlayın; mağaza ve cihaz özellikleri şartsa mobil uygulamayı ikinci adım yapın. Bildirimler, mağaza süreci ve karar kriterlerini mobil uygulama mı web uygulaması mı yazısı ayrıntılı ele alıyor.

Hazır program mı, özel web uygulaması mı?

Hazır program, birçok şirket için yazılmış ve çoğunlukla abonelikle kullanılan bir yazılımdır; özel web uygulaması ise sizin iş kurallarınıza göre yazılır. İhtiyacınız standart bir işse, örneğin temel bir görev listesi ya da sıradan bir form, hazır program daha hızlı başlar. Süreciniz sizi rakiplerinizden ayıran bir kural içeriyorsa ve bu kural programın ayarlarına sığmıyorsa, özel yazılımın avantajları ağır basmaya başlar.

Özel web uygulamasının hazır programa göre avantajları iş kurallarına uyum, veri sahipliği, kullanıcı sayısına bağlı olmayan maliyet, size göre kurulan entegrasyonlar, kendi markanız ve değişiklik hızıdır:

• İş kurallarınıza uyar. Onay adımları, fiyatlama ve roller programın ayarlarına göre değil, sizin işleyişinize göre yazılır.
• Veri sizindir. Verinin nerede tutulduğunu, kimin eriştiğini ve nasıl dışa aktarılacağını siz belirlersiniz.
• Maliyet kullanıcı sayısıyla büyümek zorunda değildir. Abonelik kalemleri sıklıkla kullanıcı, şube veya işlem sayısıyla artar; özel yazılımda maliyetin büyük kısmı geliştirme ve barındırmadır.
• Entegrasyonlar size göre kurulur. Muhasebe, kargo veya eski sisteminize ihtiyacınız olan biçimde bağlanır.
• Marka ve alan adı sizindir. Müşteriniz ekranda kendi markanızı ve alan adınızı görür.
• Değişiklik sıra beklemez. Yeni bir ihtiyaç, başka bir firmanın ürün yol haritasında beklemez.

Özel web uygulamasının avantajlarının bir bedeli var: ilk sürüm daha uzun sürer, başlangıç maliyeti daha yüksektir ve sistemin bakımından birinin sorumlu olması gerekir. Yapay zekâ destekli geliştirme araçları tekrar eden kod işlerini hızlandırıp bu başlangıç farkını daraltabilir; mimari, güvenlik ve test yine deneyimli bir ekibin işidir. Ben olsam karşılaştırmayı, kendi kullanıcı ve şube sayınızla hesaplanmış 3-5 yıllık toplam maliyet üzerinden yapardım. Ayrıntılı karar kriterleri için özel yazılım mı hazır yazılım mı rehberine bakabilirsiniz.

Web uygulaması nasıl yapılır?

Web uygulaması, yazılı bir kapsamla başlayan ve tasarım, geliştirme, test ve yayın aşamalarından geçen bir süreçle yapılır; her aşama, açıp inceleyebileceğiniz bir çıktıyla bitmelidir. UlvionTech'in çalışma biçiminde aşamalar şöyle ilerler:

1. Keşif. Hangi sorunun çözüleceği, kimlerin kullanacağı ve işin bugün nasıl yürüdüğü konuşulur. Bizde bu adım 30-45 dakikalık bir görüşme ve problemin yazılı özetiyle biter.
2. Kapsam ve teklif. Roller, ekranlar, iş kuralları ve entegrasyonlar yazıya dökülür; ilk sürüme neyin girip neyin bekleyeceğine karar verilir. Sabit fiyat bu belgeden sonra verilir.
3. Tasarım ve mimari. Tıklanabilir ekranlar ve teknik plan hazırlanır; veri modeli bu aşamada netleşir.
4. Geliştirme. İş kısa döngülerle ilerler. Biz iki haftalık döngülerle çalışıyoruz; her döngü, test ortamında açıp deneyebileceğiniz çalışan bir sürümle biter.
5. Test ve kabul. Uygulama kullanım senaryolarıyla, her rol için ayrı ayrı denenir; yetki kontrolleri bu aşamanın merkezindedir.
6. Yayın ve destek. Uygulama canlıya alınır, izleme kurulur, ekip eğitilir ve süresi yazılı olarak belirlenmiş bir destek dönemi başlar.

Web uygulaması yapım adımları içinde vazgeçmeyeceğim adım yazılı kapsamdır; yazılı kapsam olmadan verilen sabit fiyata temkinli bakarım. İlk sürümü küçük tutmanın yolunu MVP planlama rehberi anlatıyor. İlk görüşmeye hazırlanırken yazılım brief şablonunu doldurmak işinizi kolaylaştırır. Yapay zekâ araçlarıyla kendiniz bir deneme yapmayı düşünüyorsanız, nerede yeterli olup nerede ekip gerektiğini yapay zekâ ile uygulama yapma yazısı tartışıyor.

Web uygulamasının süresini ve maliyetini neler belirler?

Bir web uygulamasının süresini ve maliyetini en çok rol sayısı, iş kurallarının karmaşıklığı, entegrasyonlar ve taşınacak veri belirler; ekran sayısı tek başına iyi bir ölçü değildir. Süreyi ve maliyeti büyüten beş kalem:

• Rol ve yetki sayısı. Her yeni rol, her ekranda yeni bir "görür mü, değiştirir mi" kararı demektir.
• İş kuralları ve istisnalar. "Normalde böyle ama şu müşteride farklı" cümleleri süreyi uzatır; bunları baştan listelemek tahmini netleştirir.
• Entegrasyonlar. Muhasebe, ödeme, kargo veya e-fatura bağlantılarının süresi, karşı tarafın dokümantasyonuna ve test ortamına bağlıdır.
• Veri taşıma. Excel'den ya da eski bir sistemden aktarılacak verinin temizlenmesi, beklenenden fazla iş çıkarabilir.
• Dil, raporlama ve bildirimler. İkinci dil, dışa aktarılabilir raporlar, e-posta ve SMS bildirimleri ayrı iş kalemleridir.

Maliyet için rakam vermiyorum, çünkü rol, iş kuralı, entegrasyon ve veri taşıma kalemleri projeden projeye farklı birleşir ve kaynağı olmayan bir aralık sizi yanlış yönlendirir. Teklifleri aynı ölçüyle nasıl karşılaştıracağınızı yazılım yaptırma maliyeti rehberi anlatıyor. Her kalem için "bunu ilk sürümden çıkarırsak ne kaybederiz?" diye sormak, bütçeyi küçültmenin pratik bir yoludur.

Teklif görüşmesinde neler sorulmalı?

Teklifleri aynı ölçüyle karşılaştırmak için web uygulaması teklif görüşmesinde kapsam, sahiplik, test, yedek, kişisel veri, destek ve değişiklik fiyatı üzerine şu yedi soruyu sorun:

• Kapsam belgesinde roller ve her rolün yetkileri ayrı ayrı yazıyor mu?
• Kod deposu, sunucu hesabı ve alan adı kimin adına açılacak?
• Test ortamını ne zaman görebileceğim, yeni sürümler ne sıklıkla gelecek?
• Veri yedekleri nerede tutulacak, yedekten geri yükleme denendi mi?
• Kişisel veri işleniyorsa erişim kayıtları ve saklama süreleri nasıl ele alınacak?
• Yayından sonraki destek süresi ve kapsamı yazılı mı?
• Kapsam değişirse değişiklik geliştirilmeden önce nasıl fiyatlanacak?

Web uygulaması projelerinde hangi hatalar sık yapılır?

Web uygulaması projelerindeki sık hatalar; uygulamayı site bütçesiyle istemek, rolleri sona bırakmak, ilk sürüme her şeyi koymak, hesapları yazılım firmasının adına açtırmak ve bakımı bütçelememektir.

• Uygulamayı site bütçesiyle istemek. Tanıtım sitesi bütçesiyle rollü, entegrasyonlu bir sistem beklemek, teklif aşamasında hayal kırıklığı yaratır.
• Rolleri sona bırakmak. Yetkiler sonradan eklendiğinde birçok ekranın yeniden ele alınması gerekebilir.
• İlk sürüme her şeyi koymak. Her istek ilk sürüme girerse yayın gecikir ve kullanıcı geri bildirimi geç gelir.
• Hesapları yazılım firmasının adına açtırmak. Firma değiştiğinde kod, sunucu ve alan adı rehin kalabilir.
• Bakımı bütçelememek. Yayından sonra da güvenlik güncellemeleri ve küçük değişiklikler sürer; bunların bütçesi baştan ayrılmalıdır.

Web uygulaması projesine nereden başlanmalı?

Ben olsam bir web uygulaması projesine, en çok zaman kaybettiren tek bir iş akışını seçip onun rollerini ve verisini yazıya dökerek başlardım. Örneğin siparişler telefonla alınıp Excel'de takip ediliyorsa, ilk sürüm yalnızca sipariş girişini, onayını ve durum takibini kapsardı. Raporlar, mobil uygulama ve ikinci dil sonraki sürümlere kalırdı.

Herkese açık bir tanıtım siteniz henüz yoksa, ben olsam onu web uygulamasından ayrı ve küçük bir iş olarak paralel yürütürdüm. Kod deposunu, sunucuyu ve alan adını ilk günden şirketinizin adına açtırırdım; bu, standart sözleşmemizde yer alan bir maddedir. Tek iş akışıyla başlamanın faydası, ilk birkaç geliştirme döngüsünün sonunda kullanıcıların elinde çalışan bir sürüm olmasıdır. Özel web uygulaması geliştirme hizmetimizin kapsamını web uygulamaları sayfasında bulabilirsiniz.

Web uygulaması ne zaman yaptırılmamalı?

İhtiyaç bir web sitesiyle, hazır bir programla ya da mevcut araçlarınızı düzenleyerek çözülüyorsa web uygulaması yaptırmayın. Şu durumlarda bizimle çalışmanızı da önermem:

• İhtiyaç bir tanıtım sitesiyse. Kimse giriş yapmayacaksa uygulama bütçesi ayırmanın anlamı yok; küçük ve hızlı bir site yeter.
• Süreç standartsa ve hazır program yetiyorsa. İş kurallarınız abonelikli bir programın ayarlarına sığıyorsa, önce onu denemek daha mantıklıdır.
• Süreç henüz belli değilse. İşin nasıl yürüyeceği ekipte netleşmediyse yazılım bu belirsizliği çözmez; birkaç hafta bir tabloyla deneyip kuralları netleştirmek daha ucuzdur.
• İçeride sistemi sahiplenecek kimse yoksa. Bir web uygulaması, sorulara cevap verecek ve öncelikleri belirleyecek bir sorumlu ister.
• Şirket içinde bu işi yapabilecek bir geliştirme ekibiniz varsa. Dışarıdan bir ekip ancak belirli bir parça ya da kapasite açığı için anlamlı olur.

İhtiyacınızın site mi uygulama mı olduğundan emin değilseniz, kullanıcılarınızın ekranda ne yapacağını üç dört cümleyle yazıp iletişim sayfasından bize gönderebilirsiniz. İlk görüşmede bu cümleler üzerinden ihtiyacınızın bir site mi, bir uygulama mı olduğunu birlikte netleştiririz.