İçindekiler · 9 başlık
Müşterilerinizin telefondan randevu almasını, sipariş vermesini veya hesabını yönetmesini istiyorsunuz. Bunun için mağazadan indirilen bir mobil uygulama mı, telefon tarayıcısında çalışan bir web sitesi mi gerekiyor? Kararı görünüşe göre değil, müşterinin yapacağı işe ve işletmenizin sürdürebileceği operasyon yüküne göre verebilirsiniz.
Önce müşterinin telefonda yapacağı işi tanımlayın
Bir mobilya atölyesini düşünün: Müşteri Google'dan işletmeyi buluyor, örnek işleri inceliyor ve ölçü için talep bırakıyor. Bu akışta müşteriye uygulama indirtmek ek bir adım oluşturur. İyi hazırlanmış mobil web sayfası, müşterinin sizi tanımadan başlattığı bu yolculuğu tamamlayabilir.
Bir başka senaryoda müşteriniz her hafta aynı işletmeden sipariş veriyor, eski siparişini tekrarlıyor ve teslimat durumunu izliyor. Burada kayıtlı hesap, tekrar kullanım ve kişiselleştirilmiş akış daha fazla önem kazanır. Uygulama seçeneğini değerlendirmek anlamlı olabilir; fakat bu ihtiyaçların hangilerinin web üzerinden karşılanabildiğini de inceleyin.
Karar toplantısına özellik listesiyle değil, tek bir cümleyle başlayın: “Müşterimiz şu durumda şu işi tamamlayacak.” Ardından işlemin sıklığını, internet bağlantısını ve cihaz ihtiyacını yazın. Bu kısa tanım, gereksiz teknoloji tartışmalarını azaltır ve tekliflerin aynı ihtiyaca dayanmasını sağlar.
Mobil web, PWA ve mobil uygulama arasındaki fark nedir?
Mobil uyumlu web sitesi, farklı ekranlarda kullanılabilen ve bağlantıyla açılan sayfalardır. Hizmet tanıtımı, ürün inceleme, form, rezervasyon ve hesap yönetimi gibi işler için geliştirilebilir. Web sitesi yalnızca tanıtım broşürü olmak zorunda değildir; işlevli bir müşteri paneli de sunabilir.
PWA, web teknolojileriyle geliştirilip uygulamaya benzer deneyimler sunabilen bir web uygulamasıdır. Kurulum, çevrimdışı çalışma ve bazı cihaz yetenekleri desteklenebilir; kullanılabilir özellikler tarayıcı ve işletim sistemine göre değişir. Kaynak: MDN PWA rehberi, erişim 28 Ekim 2026.
Mobil uygulama ise telefonun işletim sistemini hedefleyen bir üründür. Ayrı platform geliştirmesi veya ortak kod yaklaşımı kullanılabilir. Mağaza dağıtımı, platform gereksinimleri ve cihaz testleri ayrıca planlanır; müşterinin uygulamayı neden yükleyip kullanmaya devam edeceği de ürün kararının parçasıdır.
| İhtiyaç | Önce değerlendirilecek seçenek | Kontrol edilecek nokta |
|---|---|---|
| Aramadan gelen ziyaretçiye hizmet anlatmak | Mobil web | Hızlı açılış ve anlaşılır talep formu |
| Bağlantıyla kullanılan müşteri paneli | Web uygulaması veya PWA | Hesap akışı ve hedef tarayıcılar |
| Sık tekrar edilen müşteri işlemleri | Web ve mobil uygulama karşılaştırması | Kurulumdan sonra devam eden fayda |
| Sahada cihaz özellikleriyle çalışma | Mobil uygulama veya uygun PWA | Gerekli donanımın gerçek cihazda denenmesi |
Hangi durumda mobil web ile başlamak yeterlidir?
İşletmenizi henüz tanımayan kişilere ulaşmak, hizmetlerinizi açıklamak ve talep toplamak istiyorsanız mobil web güçlü bir başlangıç adayıdır. Müşteri bağlantıya dokunarak hizmete ulaşır. Bu akışta önemli olan açılış hızı, okunabilir bilgi ve tamamlanabilir formdur.
Örneğin teknik servis için marka seçimi, arıza açıklaması ve uygun zaman talebi içeren bir form tasarlanabilir. Talep işletmenin paneline düşer ve çalışan müşteriyi arar. Müşterinin yalnızca yılda birkaç kez yaptığı bu işlem için uygulama hazırlamadan önce mevcut web akışının yeterliliğini ölçebilirsiniz.
- İlk ziyaret baskınsa: Hizmet, güven unsurları ve iletişim akışını öne alın.
- İşlem seyrekse: Müşterinin yeniden giriş yapma ve sizi bulma biçimini basitleştirin.
- İçerik önemliyse: Her hizmet için açıklayıcı, bağlantıyla erişilebilir sayfalar planlayın.
- Kapsam değişiyorsa: Önce küçük bir web akışıyla gerçek kullanım ihtiyacını doğrulayın.
Mobil webin temel gerekliliklerini mobil uyumlu web sitesi rehberinde inceleyebilirsiniz. Seçeneği yalnızca ilk kurulum maliyetiyle değerlendirmeyin. İçerik güncellemesi, panel kullanımı ve yayın sonrası destek de işletmenizin ihtiyacına uygun olmalıdır.
Mobil uygulamayı hangi ihtiyaçlar öne çıkarır?
Telefonun kamerasıyla düzenli kayıt alan, sahada iş emri tamamlayan veya müşterinin hesabıyla sık işlem yaptığı bir ürün düşünün. Bu senaryolarda uygulamaya özel akışlar değer yaratabilir. Ancak “kamera kullanacağız” demek tek başına yeterli gerekçe değildir; webdeki olanaklar da hedef cihazlarda denenmelidir.
Örneğin bir saha çalışanı aynı gün farklı adreslerde cihaz fotoğrafı çekip servis kaydı oluşturabilir. Uygulamada görev listesi, fotoğraf ekleme, taslak saklama ve sunucuya gönderim birlikte tasarlanır. Çalışanın bağlantı kesildiğinde hangi işleri tamamlayabileceği açıkça belirlenir.
Çevrimdışı çalışma, uygulama kurulduğu anda kendiliğinden gelen bir özellik değildir. Hangi verinin cihazda tutulacağı, değişikliklerin ne zaman gönderileceği ve çakışan kayıtların nasıl çözüleceği tasarlanmalıdır. Bu yaklaşımı örnekleyen Flutter çevrimdışı çalışma rehberi, okuma, yazma ve eşitleme kararlarını ayrı ele alır; erişim 28 Ekim 2026.
Maliyet karşılaştırmasını nasıl yapmalısınız?
Web ile uygulamanın fiyatını karşılaştırırken aynı iş akışını esas alın. Web teklifinde yalnızca form, uygulama teklifinde ise ödeme, panel ve bildirim bulunuyorsa toplamlar karşılaştırılabilir değildir. Ortak kapsamı çıkarın; platforma özgü ek işleri ayrıca görün.
Hesap yöntemini göstermek için tamamen varsayımsal bir örnek kullanalım: Web akışı 20, uygulama ve ek test işleri 35 kişi-gün olarak tahmin edilmiş olsun. Varsayımsal 6.000 TL kişi-gün bedeliyle geliştirme toplamları 120.000 TL ve 210.000 TL olur. Bunlar piyasa fiyatı veya Navdion teklifi değildir; KDV, altyapı, lisans ve mağaza giderleri dahil değildir.
Bu örnek, uygulamanın her zaman belirli oranda pahalı olacağını söylemez. Hazır sistemler, mevcut sunucu, yeniden kullanılabilir tasarım ve entegrasyon durumu sonucu değiştirir. Kapsamı ve varsayımları belirlenmemiş bir fiyat farkına dayanarak karar vermeyin.
Doğru başlangıç, müşterinizin temel işini güvenilir biçimde tamamlayan ve işletmenizin sürdürebildiği çözümdür; platform adı tek başına başarı ölçütü değildir.
Karar vermeden önce küçük bir kullanım testi yapın
Taslak ekranları birkaç gerçek kullanıcıya gösterin ve onlardan temel işlemi yardımsız tamamlamalarını isteyin. Nerede durduklarını, hangi bilgiyi aradıklarını ve hangi adımı gereksiz bulduklarını not edin. Bu çalışma satış tahmini üretmez; kullanım varsayımlarınızı sınamanıza yardım eder.
Planlama örneği olarak ilk hafta ihtiyaç görüşmeleri ve taslak, ikinci hafta kullanıcı denemeleri ve kapsam kararı ayırabilirsiniz. Bu süre bir standart veya teslim sözü değildir; karar vericilere erişim ve akışın karmaşıklığına göre değişir. Önemli olan tasarımı onaylamadan önce belirsiz noktaları görünür kılmaktır.
- Görev verin: “Gelecek salı için servis talebi oluşturun” gibi gerçek bir iş seçin.
- Gözlemleyin: Kullanıcıyı yönlendirmeden takıldığı adımları kaydedin.
- Koşulları değiştirin: Küçük ekran, yavaş bağlantı ve tekrar ziyaret senaryolarını deneyin.
- Kararı yazın: Seçilen platformun hangi ihtiyacı karşıladığını ve ertelenen işleri belirtin.
Ölçüm planına yalnızca sayfa ziyaretini eklemeyin. Başlayan ve tamamlanan talepleri, yarım bırakılan adımları ve tekrar kullanımı da takip edin. Kişisel veri toplamadan önce ölçümün amacını ve gerçekten gereken bilgileri netleştirin; gereksiz ayrıntılar kararınızı iyileştirmeyebilir.
Web ile başlayıp sonra uygulamaya geçilebilir mi?
Evet, fakat geçişin zahmetsiz olacağını varsaymayın. Müşteri kayıtları, ürün verileri ve iş kuralları sunucu tarafında düzenli tutuluyorsa sonraki platform için ortak bir temel oluşturulabilir. Ekranların ve cihaz davranışlarının ise yeniden değerlendirilmesi gerekir.
Başlangıç teklifine veri dışa aktarımını, hesap sahipliğini ve entegrasyon belgelerini ekletin. Böylece platform değişikliği gündeme geldiğinde elinizde kullanılabilir bilgi bulunur. Müşterilerinizin webdeki hesabını uygulamada kullanması isteniyorsa bu hedefi de ilk analizde belirtin.
Sık yapılan hata, ileride çıkabilecek her ihtiyaç için bugünden karmaşık yapı kurmaktır. Muhtemel büyüme noktalarını kaydedin; ilk sürümde yalnızca doğrulanmış işleri tamamlayın. Sonraki yatırım kararını kullanıcı geri bildirimi ve işletme verisiyle verin.
Yayın sonrasındaki sorumluluğu kim üstlenecek?
Seçiminizi yaptıktan sonra ürünün günlük yönetimini düşünün. Hizmet açıklamasını kim değiştirecek, yeni çalışanı kim ekleyecek ve müşteri yanlış bilgi verdiğinde kaydı kim düzeltecek? Bunların her biri için yazılım ekibine başvurmak gerekiyorsa ilk teslimden sonra sürekli bir iş kuyruğu oluşabilir.
İşletme panelinin örnek görevlerini teklif aşamasında gösterin. Örneğin çalışma saatini değiştiren yönetici, bunun müşteri tarafındaki sonucunu da görebilsin. Panelin kullanımını ürünün dışında kalan teknik bir ayrıntı olarak bırakmayın; müşteriye sunulan bilginin güncelliği bu ekrana bağlı olabilir.
Destek planında hata bildirimini, içerik güncellemesini ve yeni özellik isteğini ayırın. Sunucu ve hesap erişimlerinin işletmenizde kim tarafından takip edileceğini belirleyin. Ekip veya tedarikçi değiştiğinde kullanılacak kurulum ve devir belgeleri de teslim listesinde bulunsun.
Son bir kontrol olarak seçtiğiniz çözümü üç farklı kişinin gözünden değerlendirin: ilk kez gelen müşteri, tekrar kullanan müşteri ve sistemi yöneten çalışan. Birine kolaylık sağlayan karar diğerinde gereksiz işlem oluşturuyorsa akışı yeniden ele alın.
Sonuç: Platformu kullanım senaryosuna göre seçin
Önce müşterinin yapacağı işi, sonra tekrar sıklığını ve cihaz gereksinimlerini belirleyin. Aynı kapsam üzerinden mobil web, PWA ve uygulama tekliflerini karşılaştırın; kararı küçük bir kullanıcı testiyle destekleyin. Navdion ile işletmenize uygun başlangıç yolunu değerlendirmek için ücretsiz proje analizi talep edebilirsiniz.
Sıkça sorulan sorular
Karar, müşterinin yapacağı işe ve kullanım sıklığına bağlıdır. İlk ziyaret, hizmet tanıtımı ve basit talep akışında mobil web değerlendirilebilir. Düzenli kullanım ve cihaz ihtiyaçları varsa uygulama seçeneğini de gerçek senaryolarla karşılaştırın.
PWA, web teknolojileriyle uygulamaya benzer deneyimler sunabilir. Kurulum ve cihaz yetenekleri tarayıcı ile işletim sistemine göre değişir. Mobil uygulamada da platforma özgü geliştirme, test ve dağıtım işleri planlanır.
Evet, ancak geçişin kapsamı başlangıç mimarisine bağlıdır. Veri, hesaplar ve iş kuralları düzenli tutulursa ortak bir temel kullanılabilir. Ekranlar, cihaz davranışları ve yeni testler ayrıca değerlendirilir.
Çevrimdışı çalışma ayrıca tasarlanması gereken bir özelliktir. Hangi verilerin cihazda tutulacağı, değişikliklerin nasıl aktarılacağı ve çakışmaların nasıl çözüleceği belirlenmelidir. Uygulamanın yüklenmiş olması bütün işlemlerin çevrimdışı çalışacağını göstermez.