Web Yazılım
Hazır paket çözümlerin karşılamadığı işletmeye özel süreçler için web tabanlı yazılım planlama, geliştirme ve bakım sürecinin nasıl işlediği.
Ücretsiz ön görüşme
Formu doldurun, en kısa sürede sizi arayalım.
Dr. Harun Gümüş yazdı ve içerik olarak gözden geçirdi · · Künye ve kaynaklar
Birlikte çalıştığımız markalardan bazıları
Vitrin
Ekranların üzerine gelerek sayfaları kaydırabilirsiniz.
01 · Genel bakış
Web tabanlı özel yazılım, bir işletmenin hazır paket programların karşılamadığı, kendine özgü bir iş sürecini destekleyen; tarayıcı üzerinden erişilen bir uygulamanın planlanması, geliştirilmesi ve işletmeye teslim edilmesidir. Bu rehber, hangi durumda özel yazılımın gerçekten gerekli olduğunu, sürecin nasıl ilerlediğini ve nelerin bu hizmetin kapsamı dışında kaldığını anlatır.
Web tabanlı özel yazılım, bir işletmenin belirli bir iş sürecini (stok takibi, randevu yönetimi, saha ekibi raporlama, iç onay akışı gibi) desteklemek üzere, o işletmeye özel olarak tasarlanan ve tarayıcı üzerinden erişilen bir uygulamadır. "Web tabanlı" ifadesi, uygulamanın ayrı bir kurulum dosyası gerektirmeden, internet tarayıcısı üzerinden kullanılabildiği anlamına gelir; bu sayede farklı cihazlardan (bilgisayar, tablet, telefon) erişim mümkün olur.
Bu hizmet, herkese açık bir web sitesinden farklıdır: genellikle işletme içi kullanıcılar (personel, bayi, tedarikçi) için tasarlanır ve arama motorları tarafından indekslenmesi beklenmez. Buna karşın, aynı teknik disiplinler (güvenlik, performans, kullanılabilirlik) bu tür uygulamalar için de geçerlidir.
01Hazır paket programlar (muhasebe yazılımı, CRM, proje yönetim aracı gibi), çok sayıda işletmenin ortak ihtiyaçlarını karşılamak üzere tasarlanır ve genellikle belirli bir akışa uyulmasını bekler. Bu akış işletmenin gerçek sürecine uyuyorsa, hazır bir paket program hem daha hızlı kurulur hem de daha düşük maliyetlidir. Ancak işletmenin süreci hazır aracın varsayımlarına uymuyorsa — örneğin birden fazla hazır aracın birbirine bağlanması, veya sektöre özgü bir onay/hesaplama mantığının uygulanması gerekiyorsa — özel yazılım, sürecin olduğu gibi desteklenmesini sağlar.
Bu nedenle bu hizmetin ilk adımı her zaman bir ihtiyaç değerlendirmesidir: işletmenin süreci gerçekten özel yazılım gerektiriyor mu, yoksa piyasada olgunlaşmış bir hazır araçla mı daha hızlı ve daha az riskli şekilde çözülebilir? Bu değerlendirme, işletmenin çıkarına aykırı olsa bile dürüstçe yapılır; her ihtiyaç sıfırdan yazılım gerektirmez. Bazı durumlarda hibrit bir yaklaşım da mümkündür: sürecin bir kısmı hazır bir araçla, yalnızca hazır aracın karşılamadığı özel kısım ise küçük bir özel modülle desteklenebilir; bu, tam kapsamlı bir özel yazılımdan daha düşük maliyetli bir ara çözüm olabilir.
02Web tabanlı bir uygulama, internet üzerinden erişilebilir olduğu için güvenlik açıklarına karşı da erişilebilirdir. OWASP (Open Web Application Security Project), web uygulamalarında en sık görülen güvenlik risklerini (yetkisiz erişim, güvenli olmayan veri girişi işleme, hatalı yapılandırma gibi) düzenli olarak belgeler. Bu rehberde anlatılan geliştirme sürecinde, kullanıcı kimlik doğrulama, yetkilendirme ve veri girişi denetimi gibi temel güvenlik unsurları, uygulamanın sonradan eklenen değil, baştan tasarlanan bir parçası olarak ele alınır.
Bu yaklaşımın pratik nedeni basittir: bir güvenlik açığı sonradan fark edildiğinde, düzeltme maliyeti genellikle baştan doğru tasarlamaktan daha yüksektir; bazı durumlarda ise veri kaybı veya yetkisiz erişim gibi geri döndürülemez sonuçlar doğurabilir.
03ISO/IEC 25010 standardı, yazılım ürün kalitesini işlevsel uygunluk, performans verimliliği, uyumluluk, kullanılabilirlik, güvenilirlik, güvenlik, sürdürülebilirlik ve taşınabilirlik gibi ölçütlerle tanımlar. Bu rehberde "kaliteli yazılım" ifadesi, yalnızca istenen işlevi yerine getiren değil, aynı zamanda ileride bakımı yapılabilir, güvenli ve öngörülebilir biçimde çalışan yazılım anlamına gelir. Geliştirme sürecinin her aşamasında bu ölçütler, tek seferlik bir "çalışıyor mu" testinden daha geniş bir çerçeve olarak kullanılır.
04Bir web uygulaması, ayrı bir kurulum dosyası olmasa da, tarayıcıda yüklenme hızı ve tepki verme süresi açısından kullanıcı deneyimini doğrudan etkiler. Core Web Vitals ölçütleri (yükleme hızı, görsel kararlılık, etkileşim gecikmesi) yalnızca herkese açık web siteleri için değil, işletme içi kullanılan uygulamalar için de geçerli bir referans çerçevesi sunar; özellikle günlük olarak yoğun kullanılan bir iç araçta yavaşlık, doğrudan çalışan verimliliğini etkiler.
05Hayır. Ürün kataloğu, sepet ve ödeme altyapısı gerektiren e-ticaret ihtiyaçları için piyasada olgunlaşmış, yaygın kullanılan hazır platformlar mevcuttur; bu platformlar, ödeme güvenliği ve sektör uyumluluğu gibi konularda yıllar içinde test edilmiş çözümler sunar. Bu nedenle bu rehberde e-ticaret ihtiyacı, sıfırdan özel yazılım geliştirme kapsamında değil, web tasarım hizmet alanındaki e-ticaret sitesi kurulumu kapsamında ele alınır. Yalnızca hazır platformların gerçekten karşılayamadığı, sektöre çok özgü bir satış süreci varsa, bu durum ayrıca ve dürüstçe değerlendirilir.
06Bir işletme sürecine özel geliştirilen yazılım, genellikle o işletmenin en değerli verilerinden bazılarını (müşteri kaydı, stok bilgisi, operasyonel geçmiş) barındırır. Bu nedenle veri yedekleme sıklığı ve kurtarma planı, uygulamanın işlevleriyle birlikte, mimari aşamasında baştan planlanır; sonradan eklenmesi gereken bir ek özellik olarak değil, uygulamanın temel bir parçası olarak ele alınır. Yedekleme mekanizmasının düzenli olarak çalıştığının doğrulanması da bu planın bir parçasıdır; yalnızca kurulmuş olması yeterli görülmez.
Erişim yetkilendirmesi de aynı titizlikte ele alınır: hangi kullanıcının hangi veriye erişebileceği, gereksinim dokümanında rol bazlı olarak tanımlanır. Bu, hem güvenlik hem de kullanılabilirlik açısından önemlidir — gereğinden geniş yetki, veri sızıntısı riskini artırırken, gereğinden dar yetki, günlük kullanımı zorlaştırır.
07Bir işletmenin bugünkü kullanıcı sayısı ve veri hacmi, birkaç yıl içinde önemli ölçüde değişebilir. Mimari seçimi yapılırken, işletmenin belirttiği büyüme beklentisi dikkate alınır; ancak bu, her projede en karmaşık ve en pahalı altyapının seçilmesi anlamına gelmez. Küçük ölçekli bir ihtiyaç için gereğinden büyük bir altyapı kurmak, gereksiz maliyet ve bakım yükü doğurur; bu nedenle ölçek kararı, işletmenin gerçek ve makul büyüme beklentisine göre dengelenir.
60 saniyelik dijital karne
Altı soruyu Evet, Kısmen ya da Hayır diye yanıtlayın; sitenizin dijital karne puanını, öncelikli iki alanı ve uygun başlangıç paketini görün. Cevaplarınız yalnızca bu sayfada değerlendirilir.
Önerilen başlangıç:
Puan genel bir öz değerlendirmedir; kesin durum ön görüşmedeki incelemeyle belirlenir.
Hizmetler
Her hizmetin kapsamı, süreci ve ücreti belirleyen etkenler kendi sayfasında anlatılır.
Neden önemli?
Hazır yazılımlara sığmayan iş süreçleri için sistem modüller halinde kurulur; ihtiyaç büyüdükçe yeni parçalar eklenir.
Her site, kurulumdan sonra da izlenebilsin diye ölçüm araçlarıyla birlikte teslim edilir.
Rakamlar bu sitedeki proje sayfalarından otomatik hesaplanır.
02 · Kimler için
Bu hizmet; iş sürecini yürütmek için birden fazla dağınık aracı (elektronik tablo, mesajlaşma uygulaması, kağıt form) bir arada kullanan, bu araçlar arasında veri kaybı veya tutarsızlık yaşayan, ya da piyasadaki hazır yazılımların sektörüne veya sürecine tam uymadığını fark eden işletmeler için anlamlıdır.
01Özel yazılım ihtiyacı yalnızca nadir veya çok özel sektörlerde ortaya çıkmaz; oldukça yaygın işletme türlerinde de, o işletmenin kendine özgü bir kuralı veya iş akışı varsa aynı ihtiyaç doğabilir. Belirleyici olan sektör değil, sürecin hazır bir aracın varsayımlarına uyup uymadığıdır. Bu nedenle değerlendirme, işletmenin sektöründen bağımsız olarak, sürecin kendisine bakılarak yapılır.
02Tipik ihtiyaç alanları arasında iç saha ekibi raporlama araçları, stok/envanter takip panelleri, randevu veya rezervasyon yönetim sistemleri, bayi/tedarikçi portalları ve özel onay/iş akışı uygulamaları sayılabilir. Bu liste kapsayıcı değildir; her işletmenin süreci farklı olduğundan, ihtiyaç ancak keşif görüşmesinde netleşir.
03Keşif görüşmesi sonunda, işletmenin ihtiyacının piyasadaki hazır bir araçla daha hızlı ve daha düşük maliyetle karşılanabileceği görülürse, bu açıkça belirtilir ve özel yazılım süreci başlatılmaz. Bu yaklaşım, kısa vadede daha az gelir anlamına gelse de, işletmenin gerçek ihtiyacına uygun karar vermesini önceliklendirir.
04Bazı işletmelerin elinde zaten eski, bakımı zorlaşmış veya artık ihtiyacı karşılamayan bir yazılım bulunur. Bu durumda süreç, sıfırdan yazılımdan farklı olarak, önce mevcut sistemin hangi bölümlerinin korunabileceğinin ve hangi verinin yeni sisteme taşınması gerektiğinin incelenmesiyle başlar. Veri taşıma (migrasyon), özellikle geçmiş kayıtların bütünlüğünün korunması açısından ayrı bir dikkat gerektiren bir aşamadır.
05Bazı işletmelerin kendi bünyesinde küçük bir teknik ekibi veya tek bir geliştiricisi olabilir. Bu durumda, özel yazılım süreci bu ekiple çakışan değil, onu tamamlayan bir çalışma olarak kurgulanır: örneğin ek kapasite gereken bir dönemde belirli bir modülün geliştirilmesi üstlenilebilir, veya mevcut ekibin zamanının yetmediği bir mimari planlama aşamasında destek sağlanabilir. Bu tür bir işbirliğinde, kod tabanının kime ait olduğu ve hangi tarafın hangi bölümden sorumlu olacağı baştan yazılı olarak netleştirilir.
06Özel yazılım geliştirme, hazır bir paket programdan doğası gereği daha uzun sürer ve daha yüksek bir başlangıç yatırımı gerektirir; bunun karşılığı, sürecin işletmenin gerçek ihtiyacına birebir uyacak şekilde tasarlanmasıdır. Kesin bir süre veya bütçe önceden ilan edilmez; kapsam, keşif görüşmesi sonrası netleştirilip yazılı bir teklif olarak paylaşılır. Küçük kapsamlı bir araç haftalar içinde, çok modüllü bir sistem ise aylar içinde tamamlanabilir; bu fark tamamen kapsama bağlıdır.
07Teknik olarak doğru çalışan bir uygulama, çalışanlar tarafından kullanılmıyorsa amacına ulaşmaz. Bu nedenle, uygulamanın günlük kullanıcılarının (yalnızca karar vericilerin değil, fiilen kullanacak personelin) ihtiyaçları da gereksinim aşamasında dinlenir; kullanıcı arayüzünün, mevcut iş alışkanlıklarına makul ölçüde yakın tasarlanması, benimseme sürecini kolaylaştırır. Kullanıcıların değişime dirençli olabileceği durumlarda, yayına almadan önce küçük bir pilot kullanım dönemi önerilir.
Standart bir sürecin (örneğin genel muhasebe, temel proje takibi) hazır bir araçla zaten iyi karşılandığı işletmeler için özel yazılım genellikle gereksiz bir maliyettir. Aynı şekilde, sürekli değişen ve henüz netleşmemiş bir sürecin özel yazılıma dönüştürülmesi, sık revizyon ihtiyacı doğurabileceğinden, süreç biraz daha oturana kadar ertelenmesi önerilebilir.
Süreç
Görüşme, işletmenin mevcut sürecinin nasıl işlediğinin ve neyin dağınık/verimsiz kaldığının anlaşılmasıyla başlar. Bu aşamada, ihtiyacın gerçekten özel yazılım mı yoksa hazır bir araç mı gerektirdiği dürüstçe değerlendirilir.
Özel yazılımın gerekli olduğuna karar verilirse, hangi işlevlerin uygulamada yer alacağı, kimlerin hangi yetkiyle erişeceği ve hangi verinin nasıl saklanacağı yazılı bir gereksinim dokümanında netleştirilir. Bu doküman, sonraki aşamaların referans noktasıdır.
Uygulamanın veri modeli, kullanılacak teknoloji ve barındırma yaklaşımı belirlenir. Bu seçim, işletmenin ölçeğine ve gelecekteki büyüme beklentisine göre yapılır; gereğinden karmaşık bir mimari, gereksiz maliyet ve bakım yükü doğurur.
Uygulama, gereksinim dokümanına göre aşamalı olarak geliştirilir. Kapsamı büyük projelerde, geliştirme genellikle küçük parçalara (modüllere) bölünür ve her modül tamamlandıkça işletmeyle birlikte gözden geçirilir; bu, kapsam sapmasının erken fark edilmesini sağlar.
Uygulama; işlevsel doğruluk, güvenlik (OWASP'ın tanımladığı temel risk kategorilerine karşı) ve farklı cihaz/tarayıcı uyumluluğu açısından test edilir. Test aşaması, yayına alma öncesindeki son kontrol noktasıdır ve atlanmaz.
Uygulama, işletmenin kullanacağı ortamda yayına alınır ve kullanıcıların (personel, bayi gibi) yeni araca alışması için kısa bir kullanım eğitimi veya kılavuz sağlanır. Yeni bir aracın benimsenmemesi, teknik başarıdan bağımsız olarak projenin faydasını sınırlayabilir; bu nedenle eğitim adımı atlanmaz.
Geliştirme tamamlandığında, yalnızca çalışan yazılım değil, o yazılımın nasıl kurulduğu, hangi bileşenlerden oluştuğu ve gerekirse nasıl güncelleneceğini anlatan temel bir teknik dokümantasyon da teslim edilir. Bu dokümantasyon, işletmenin ileride başka bir geliştirici veya ekiple devam etmek istemesi durumunda kritik önem taşır; dokümantasyonu olmayan bir yazılım, yalnızca onu yazan kişiye bağımlı kalır ve bu bağımlılık işletme için bir risktir.
En sık karşılaşılan hata, gereksinimlerin net biçimde yazılı hâle getirilmeden geliştirmeye başlanmasıdır; bu durum, geliştirme ilerledikçe kapsamın belirsizleşmesine ve revizyon sayısının artmasına yol açar. İkinci sık hata, güvenlik ve yedekleme gibi "görünmeyen" gereksinimlerin, yalnızca görünür işlevlere odaklanılarak ihmal edilmesidir. Üçüncü bir hata ise, test aşamasının kısaltılarak doğrudan yayına geçilmesidir; bu, küçük bir hatanın canlı ortamda büyük bir soruna dönüşmesine yol açabilir.
Yayına alınan bir yazılım, statik bir web sayfasının aksine, zamanla güvenlik güncellemesi, hata düzeltmesi ve gerekirse yeni işlev eklenmesi ihtiyacı doğurur. Bu ihtiyaç, talep hâlinde ayrı bir bakım anlaşmasıyla karşılanır; anlaşma olmadan da işletme, teslim edilen kaynak koda sahip olduğu için bakımı kendi ekibine veya başka bir sağlayıcıya devrettirebilir.
Geliştirme süreci boyunca, işletmenin ilerleyişi yalnızca proje sonunda değil, düzenli aralıklarla görebilmesi sağlanır. Bu, tamamlanan modüllerin ara sunumlarla gösterilmesi ve varsa gecikme veya kapsam sapması riskinin erken paylaşılması şeklinde işler. Sürpriz bir gecikme veya kapsam değişikliğiyle proje sonunda karşılaşılması yerine, bu tür durumların anında ve yazılı olarak bildirilmesi tercih edilir.
Kapsam ve gereksinim kararları işletmeyle birlikte, yazılı gereksinim dokümanı üzerinden alınır. Teknik mimari ve teknoloji seçimi gibi kararlar ise, işletmenin belirttiği kısıtlar (mevcut altyapı, bütçe, ölçek beklentisi) çerçevesinde, teknik gerekçesi açıklanarak önerilir; nihai onay yine işletmenindir.
Uygulamada
Aşağıdaki örnekler, gerçek bir müşteri vakası değil, bu hizmetin tipik olarak hangi tür ihtiyaçlara nasıl yaklaştığını göstermek amacıyla hazırlanmış anonim senaryolardır.
Örnek senaryo 01
Bir işletme, saha ekibinin günlük raporlarını mesajlaşma uygulaması üzerinden topluyor ve bu verileri elle bir elektronik tabloya aktarıyor olabilir. Bu durumda ihtiyaç değerlendirmesi, verinin doğrudan girilebileceği, yetkiye göre görünürlüğü ayarlanmış basit bir web tabanlı raporlama panelinin gerçekten gerekli olup olmadığını netleştirir. Gerekli görülürse, kapsam en kritik alanlarla (veri girişi, temel görüntüleme) sınırlı tutularak başlatılır; sonuç, işletmenin sürecine ve veri hacmine göre değişir.
Örnek senaryo 02
Bir işletmenin yıllar önce yaptırılmış, artık bakımı yapılamayan bir iç yazılımı olabilir. Bu durumda süreç, önce mevcut verinin bütünlüğünün korunarak yeni sisteme aktarılmasının planlanmasıyla başlar; ardından eksik veya güncelliğini yitirmiş işlevler yeniden tasarlanır. Böyle bir yenileme sürecinin süresi, mevcut verinin karmaşıklığına bağlı olarak değişir.
Örnek senaryo 03
Bir işletmenin kendi bünyesinde tek bir geliştiricisi olabilir ve bu kişi, büyüyen bir modülün mimarisini tek başına tasarlamakta zorlanıyor olabilir. Bu durumda hizmet, işletmenin mevcut ekibinin yerini almak yerine, belirli bir modülün mimari planlamasında veya yoğun bir dönemde ek geliştirme kapasitesi olarak devreye girer. Sorumluluk sınırları ve kod tabanının kime ait olacağı, işbirliği başlamadan önce yazılı olarak netleştirilir.
Örnek senaryo 04
Bazı görüşmeler, işletmenin ihtiyacının aslında piyasadaki hazır bir araçla karşılanabileceğinin fark edilmesiyle sonuçlanır. Bu durumda özel yazılım süreci başlatılmaz; bunun yerine, hangi hazır aracın uygun olabileceği konusunda genel bir yönlendirme yapılır. Bu, her ihtiyacın otomatik olarak özel yazılım gerektirmediğini gösteren, bilinçli olarak dahil edilmiş bir örnektir; amaç, işletmeyi gereksiz bir yatırıma yönlendirmek değil, gerçek ihtiyaca en uygun çözümü göstermektir.
Örnek senaryo 05
Bir işletmede, bir talebin (satın alma, izin, harcama gibi) onaylanması için birden fazla kişinin sırayla e-posta veya kağıt üzerinden onay vermesi gerekebilir; bu süreçte hangi talebin kimde beklediği genellikle net değildir. Bu durumda ihtiyaç değerlendirmesi, onay adımlarının ve yetkilerin tek bir web tabanlı akışta toplanmasının gerçekten gerekli olup olmadığını inceler; sonuç, işletmenin onay adımı sayısına ve talep hacmine göre değişir.
Paketler
İhtiyacınıza en yakın paketi seçin; ayrıntıları ilk görüşmede birlikte netleştirelim.
Mevcut sisteme eklenecek tek bir modül veya üçüncü taraf entegrasyonu.
Teklif alınTek iş kalemi
Bu paket için görüşelimİş süreçlerinize göre sıfırdan geliştirilen web tabanlı yazılım.
Teklif alınProje bazlı
Bu paket için görüşelimSürekli geliştirilen sistemler için geliştirme ve bakım bir arada.
Teklif alınProje + aylık bakım
Bu paket için görüşelimPaketler başlangıç çerçevesidir; kesin kapsam, süre ve ücret keşif görüşmesinden sonra yazılı teklifle paylaşılır. İhtiyacınız paketlerin dışındaysa kapsamı birlikte belirleriz.
Sık sorulan sorular
Web Yazılım hakkında en sık sorulan sorular ve kısa yanıtları.
4 soru · kısa ve kaynaklı yanıtlar
İşletmenin süreci, piyasadaki hazır paket programların standart akışına uymuyorsa veya birden fazla hazır aracın birbirine bağlanması gerekiyorsa özel yazılım değerlendirilir. Süreç standartsa ve hazır bir araç ihtiyacı karşılıyorsa, özel yazılım genellikle gerekli değildir; bu değerlendirme keşif aşamasında dürüstçe yapılır.
Hayır. Ürün kataloğu, sepet ve ödeme altyapısı gerektiren e-ticaret ihtiyaçları için piyasada olgunlaşmış hazır platformlar (ör. yerleşik e-ticaret altyapıları) genellikle sıfırdan yazılımdan daha hızlı ve daha az risklidir; bu ihtiyaç web tasarım hizmet alanındaki e-ticaret sitesi kurulumu kapsamında ele alınır.
Aksi yazılı olarak belirtilmedikçe, tamamlanan ve bedeli ödenen özel yazılımın kaynak kodu işletmeye teslim edilir. Bu, işletmenin ileride başka bir ekiple devam edebilmesini garanti altına alır.
Yayına alınan yazılım, güvenlik güncellemeleri ve hata düzeltmeleri açısından düzenli takip gerektirir. Bu, talep hâlinde ayrı bir bakım anlaşmasıyla sürdürülür; anlaşma yoksa işletme, teslim edilen kaynak kodla bakımı kendi ekibine veya başka bir sağlayıcıya devrettirebilir.
Başlayalım
Mevcut durumunuzu dinleyelim, size uygun kapsamı ve takvimi yazılı olarak paylaşalım. İlk görüşme için bir taahhüt istemiyoruz.
Süreç nasıl başlar?
Ad ve telefon yeterli; iki dakikanızı alır.
İhtiyacınızı ve mevcut durumunuzu dinleriz.
Kapsam, takvim ve ücret yazılı olarak paylaşılır.
Yazan ve gözden geçiren: Dr. Harun Gümüş | Dijital Strateji, SEO/GEO ve Yazılım Kalite
Son gözden geçirme: · Bir sonraki gözden geçirme: 2027-09
Site editörü: mail@uzmandizayn.com.tr · Editoryal politikamız
