Mobil uygulama mı web uygulaması mı? Önce hangisini yapmalı?

Çoğu şirket için doğru ilk adım, telefonda da iyi çalışan bir web uygulamasıdır: tek kod tabanıyla başlar, mağaza onayı beklemeden güncellenir ve Google'da bulunabilir. Ürününüz kamera, arka planda konum, güvenilir bildirim ya da çevrimdışı kullanım gibi cihaz özelliklerine dayanıyorsa ve kullanıcılarınız onu her gün açacaksa, önce mobil uygulama yapmak daha doğrudur.

Bu yazı, yeni bir ürün ya da şirket içi bir araç için "mobil uygulama mı web uygulaması mı" sorusuna cevap arayan kurucular ve ürün yöneticileri için. Dört seçeneği (duyarlı web, PWA, cross-platform ve native) sade bir dille tanımlıyor, kararı belirleyen kriterleri tek tek ele alıyor ve bir karşılaştırma tablosu ile "hangi durumda hangisi" listesiyle bitiyor. Mağaza ücretleri, inceleme süreleri ve tarayıcı desteği gibi değişebilen bilgileri Apple, Google ve tarayıcı üreticilerinin kendi sayfalarından aldık; hepsi Ekim 2026 itibarıyla geçerlidir. Rakam veremediğimiz yerde, rakamı neyin büyüttüğünü ve bunu bir teklifte nasıl test edeceğinizi anlatıyoruz.

Web uygulaması ile mobil uygulama arasındaki fark nedir?

Web uygulaması tarayıcıda çalışır, bir adresle açılır ve kurulum gerektirmez; mobil uygulama App Store ya da Google Play'den indirilir, telefona kurulur ve işletim sistemiyle doğrudan çalışır. Aradaki fark yalnızca teknik değildir: kullanıcıya nasıl ulaştığınızı, ne kadar hızlı güncelleyebildiğinizi ve bütçenin nereye gittiğini belirler. Pratikte dört seçenek vardır; ikisi web, ikisi mobil tarafta durur. Aşağıda her birini bir kez tanımlıyoruz ve yazının geri kalanında bu terimleri aynı anlamda kullanıyoruz.

Duyarlı (responsive) web uygulaması

Duyarlı tasarım, aynı uygulamanın ekran genişliğine göre düzenini değiştirmesidir: masaüstünde geniş bir tablo olarak görünen sipariş listesi telefonda alt alta dizilmiş kartlara dönüşür. Müşteri portalları, rezervasyon ve teklif akışları, yönetim panelleri ve şirket içi araçların büyük kısmı bu gruptadır. Tek kod tabanı vardır, her tarayıcıda açılır ve bir bağlantıyla paylaşılır. Sınırı, cihaz özelliklerine erişimin tarayıcının izin verdiği kadarla kalması ve kullanıcının ana ekranında sizi hatırlatan bir simge olmamasıdır. Bir işi ayda birkaç kez yapan kullanıcı için bu sınır çoğu zaman hiç hissedilmez.

PWA (progressive web app)

MDN'nin tanımıyla PWA, web teknolojileriyle geliştirilen ama platforma özgü bir uygulamaya benzer deneyim sunan uygulamadır (yeni sekmede açılır). Ana ekrana eklenebilir, service worker adı verilen ve sayfa kapalıyken de çalışabilen bir arka plan betiği sayesinde içeriği önbelleğe alıp bağlantı yokken de açılabilir ve bildirim gönderebilir. Mağazadan geçmediği için inceleme beklemez. Sınırı şudur: iPhone'da bildirimler yalnızca ana ekrana eklenmiş web uygulamalarında çalışır ve ana ekrana eklemeyi kullanıcının Safari'nin Paylaş menüsünden kendisinin yapması gerekir. Google'ın geliştirici rehberi web.dev de bazı yeteneklerin hâlâ web'in erişiminin dışında olduğunu (yeni sekmede açılır) açıkça belirtir.

Cross-platform mobil uygulama

Cross-platform, tek bir kod tabanından hem iOS hem Android uygulaması üretmek demektir. En yaygın iki araçtan React Native (yeni sekmede açılır) JavaScript ile yazılır ve arayüz bileşenleri platformun kendi yerel bileşenlerine dönüşür. Flutter (yeni sekmede açılır) ise Dart diliyle yazılır ve platformun bileşenlerini kullanmak yerine kendi çizim motoruyla kendi bileşenlerini çizer. İkisi de mağazadan dağıtılır ve kamera, konum, biyometrik giriş ve bildirim gibi cihaz özelliklerine erişir. Mobil projelerde varsayılanımız React Native ve Expo'dur; platforma özgü derin bir özellik gerektiğinde o parçayı Swift ya da Kotlin ile yazarız. Bu yaklaşımı mobil uygulama geliştirme sayfamızda ayrıca anlattık.

Native mobil uygulama

Native uygulama, her platform için o platformun kendi diliyle ayrı ayrı yazılan uygulamadır: iOS için Swift, Android için Kotlin. Cihazın her özelliğine ilk günden erişir, performansı en öngörülebilir olanıdır ve platformun alışılmış davranışlarına tam uyar. Bedeli iki ayrı kod tabanıdır: iki ayrı test ve bakım hattı, çoğu zaman da iki ayrı uzmanlık. Yoğun grafik, ileri kamera işleme ya da düşük gecikmeli ses gibi işlerde bu bedel karşılığını verir. Formlar, listeler ve onay akışlarından oluşan tipik bir iş uygulaması için ise çoğu zaman gereğinden fazladır.

Karar verirken hangi kriterlere bakmalısınız?

Doğru soru "hangisi daha modern" değil, "kullanıcı bu işi hangi anda, hangi cihazda ve ne sıklıkla yapıyor" sorusudur. Aşağıdaki kriterlerin her biri sizi web'e ya da mobile doğru iter ve genellikle üç dört kritere verilen cevap yönü netleştirir. Cevabını bilmediğiniz bir kriter varsa onu bir varsayım olarak yazın ve ilk sürümde ölçülecek bir soruya dönüştürün. Bu listeyi bir yazılım firmasıyla yapacağınız ilk görüşmeye de götürebilirsiniz; iyi bir ekip bu soruları size sormalıdır.

• Kullanıcılar kim ve nerede? Masaüstünden çalışan bir operasyon ekibi web'i, yolda telefonla işlem yapan müşteriler ya da sahada çalışan teknisyenler mobili işaret eder.
• Kullanım sıklığı: Ayda bir açılan bir araç için kullanıcılar uygulama indirmeye pek istekli olmaz; her gün açılan bir araçta ana ekrandaki simge gerçek bir avantajdır.
• Cihaz özellikleri: Kamerayla barkod okuma, arka planda konum, Bluetooth ile bağlanan cihazlar ve biyometrik giriş mobile iter. Yalnızca form, liste ve rapor varsa web yeter.
• Mağaza süreci: Mobil uygulamanın her sürümü Apple ve Google incelemesinden geçer; web uygulaması yayına aldığınız anda herkeste güncellenir.
• Güncelleme hızı: Fiyatlar, kurallar ve ekranlar sık değişecekse web'in avantajı büyür.
• Bütçe ve süre: İki platform, mağaza hazırlıkları ve gerçek cihazlarda test mobil tarafı daha pahalı ve daha uzun yapar.
• Çevrimdışı çalışma: Depo, şantiye ya da kırsal saha gibi bağlantısız ortamlarda güvenilir kayıt ve sonradan eşitleme mobilde daha olgundur; PWA bunu bir ölçüde yapabilir.
• Bildirimler: Ürünün değeri zamanında gelen bir bildirime dayanıyorsa, iPhone'daki PWA sınırı kararı doğrudan etkiler.
• Keşfedilebilirlik ve SEO: Müşteriler sizi Google'da arayarak buluyorsa indekslenebilen web sayfaları şarttır; uygulamanın içindeki ekranlar, karşılığı olan bir web sayfası yoksa arama sonuçlarında kendiliğinden yer almaz.

Bu kriterleri aynı ağırlıkla saymayın. Pratikte kararı çoğu zaman üç tanesi belirler: kullanıcının nerede olduğu, ürünün bir cihaz özelliğine ne kadar bağlı olduğu ve bütçe. Diğerleri bu üç cevabı doğrular ya da sorgular. Örneğin bayilerine sipariş ekranı sunacak bir üretici için kullanıcılar masaüstündedir, cihaz özelliği gerekmez ve ürün sık değişecektir; burada web açık ara öndedir. Aynı şirketin depo personeli için barkod okutan bir sayım aracı ise kamera ve çevrimdışı çalışma gerektirdiği için mobil tarafa geçer.

Mağaza süreci, güncellemeler ve bildirimler pratikte neyi değiştirir?

Mobilde maliyetin önemli bir kısmı kodun kullanıcıya ulaşma yolundadır: mağaza, inceleme ve sürüm yönetimi. Web uygulamasında yeni bir sürümü yayına aldığınız anda herkes onu görür; mobilde ise her sürüm bir inceleme sırasına girer ve kullanıcılar güncellemeyi kendi zamanlarında yükler. Bu fark ilk sürümde küçük görünür, ürün her hafta değişmeye başladığında büyür. Bildirimler ve çevrimdışı çalışma da kâğıt üzerinde her seçenekte "var" görünür ama pratikteki sınırları farklıdır. Aşağıdaki üç başlık, kararı en çok etkileyen ayrıntıları resmî kaynaklarıyla topluyor.

Mağaza hesapları ve inceleme süresi (Ekim 2026 itibarıyla)

Ekim 2026 itibarıyla Apple Developer Program üyeliği yıllık 99 USD (yeni sekmede açılır); Apple, fiyatın bölgeye göre değişebileceğini ve kayıt sırasında yerel para birimiyle gösterildiğini belirtiyor. Google Play geliştirici hesabı ise bir defaya mahsus 25 USD (yeni sekmede açılır) kayıt ücreti istiyor. Apple, incelemelerin genellikle en az yarısını 24 saatten, yüzde 90'ını 48 saatten kısa sürede (yeni sekmede açılır) tamamladığını söylüyor; reddedilen bir sürüm bu süreyi yeniden başlatır. Google tarafında 13 Kasım 2023'ten sonra açılan kişisel geliştirici hesapları, uygulamayı yayına almadan önce en az 12 test kullanıcısının son 14 gün boyunca kesintisiz katıldığı kapalı bir test (yeni sekmede açılır) yapmak zorunda. Hesapların zaten şirketiniz adına açılması gerektiğini düşünüyoruz; bu kural da şahıs hesabıyla başlamamak için bir neden daha.

Mağazaya bir kısayolla girmeye çalışmak da işe yaramayabilir. Bir web sitesini uygulama kabuğuna sarıp yayınlamak cazip görünür, ancak Apple'ın inceleme kuralları uygulamanın paketlenmiş bir web sitesinin ötesine geçen özellik, içerik ve arayüz sunmasını (yeni sekmede açılır) istiyor (madde 4.2). Yani mağazada olmanın tek gerekçesi "mağazada olmak" ise, inceleme sizi büyük ihtimalle web'e geri gönderir.

Güncelleme hızı

Web uygulamasında bir hatayı düzelttiğinizde düzeltme birkaç dakika içinde herkese ulaşır. Mobil uygulamada ise yeni bir derleme hazırlanır, incelemeye gönderilir ve onaylandıktan sonra kullanıcıların güncellemesi beklenir; bir süre boyunca sahada birden fazla sürüm aynı anda çalışır. Bu yüzden arka uç, yani uygulamanın konuştuğu sunucu tarafı, eski sürümleri de bozmadan desteklemek zorundadır. React Native ve Expo kullanan projelerde EAS Update (yeni sekmede açılır) ile JavaScript, stil ve görsel değişiklikleri mağazaya yeni bir sürüm göndermeden dağıtılabilir; native kod, izinler ve SDK sürümü değişiklikleri ise yine yeni bir derleme ister. Bu yol hata düzeltmeleri ve küçük arayüz değişiklikleri içindir; Apple'ın inceleme kuralları (madde 2.5.2) (yeni sekmede açılır) sonradan indirilen kodun uygulamanın temel işlevini değiştirmesine izin vermediği için büyük değişiklikler yine incelemeden geçmelidir.

Bildirimler ve çevrimdışı çalışma

iPhone ve iPad'de web bildirimleri, WebKit'in duyurusuna göre iOS ve iPadOS 16.4 ile, yalnızca ana ekrana eklenmiş web uygulamaları için (yeni sekmede açılır) geldi ve izin isteği kullanıcının bir dokunuşuna yanıt olarak gösterilmek zorunda. Yani siteyi Safari'de açan bir kullanıcı, uygulamayı ana ekrana ekleyene kadar bildirim alamaz. Bildirim ürününüzün özündeyse ve kullanıcılarınızın önemli bir kısmı iPhone kullanıyorsa, bu sınır tek başına mobil uygulamayı haklı çıkarabilir. Çevrimdışı tarafta PWA'lar service worker ile ekranları ve verinin bir kısmını önbelleğe alabilir, bağlantı gelince bekleyen işlemleri gönderebilir. Ancak gün boyu bağlantısız çalışıp yüzlerce kaydı sonradan eşitleyen ve çakışmaları çözen bir saha uygulaması için mobil taraf hâlâ daha güvenilir bir zemindir.

Native, cross-platform, PWA ve duyarlı web karşılaştırma tablosu

Aşağıdaki tablo dört seçeneği yukarıdaki kriterlerin en belirleyici beşiyle yan yana koyuyor. Maliyet sütunu bir fiyat değil, aynı kapsam için seçenekler arasındaki görece farktır. Mağaza ve bildirim bilgilerinin kaynakları yukarıdaki bölümlerde; maliyet ve erişim sütunları bizim değerlendirmemizdir.

Tablo bir başlangıç noktasıdır, hüküm değildir. Bir seçeneğin satırında "en düşük maliyet" yazması, ürününüz o seçeneğin taşıyamayacağı bir özelliğe ihtiyaç duyuyorsa anlamsızdır; tersine "tam cihaz erişimi" de, kullanıcılarınız o erişimi hiç kullanmayacaksa boşa harcanmış bütçedir. Tabloyu kendi ürününüz için doldururken her hücreye "bizim için önemli mi?" sorusunu ekleyin.

Mobil uygulama mı web uygulaması mı: hangi durumda hangisi?

Kısa cevap koşulludur: ürünün özü bir cihaz özelliğine ve günlük kullanıma dayanmıyorsa web'le başlayın, dayanıyorsa mobille. Aşağıdaki üç liste, bu kuralın hangi durumlarda nasıl uygulandığını gösteriyor. Bir listeye kesin olarak uyuyorsanız karar büyük ölçüde verilmiştir; iki listeye birden uyuyorsanız asıl soru sıralama ve mimaridir.

Şu durumlarda önce web uygulamasıyla başlayın

• Kullanıcılarınız çoğunlukla masaüstündeyse: operasyon panelleri, bayi ve B2B portalları, raporlama ekranları.
• Ürünü henüz doğruluyorsanız: akışlar ve kurallar her hafta değişecekse, mağaza döngüsü öğrenme hızınızı düşürür.
• Müşterileriniz sizi aramayla buluyorsa: ürün, hizmet ve içerik sayfalarının Google'da görünmesi gerekiyorsa.
• Kullanım seyrekse: ayda birkaç kez açılan bir araç için indirme istemek kullanıcı kaybettirir.
• Bütçe tek platforma yetiyorsa: tek kod tabanı hem telefonda hem masaüstünde çalışır ve sonradan bir mobil uygulamaya temel olur.

Şu durumlarda önce mobil uygulamayla başlayın

• Ürünün özü bir cihaz özelliğiyse: barkod ya da QR okutma, arka planda konum, Bluetooth ile cihaz bağlama, biyometrik giriş.
• Kullanıcılar uygulamayı her gün açacaksa: ana ekrandaki simge ve bildirimler ürünün bir parçasıdır.
• Saha ekipleri bağlantısız çalışıyorsa: güvenilir çevrimdışı kayıt ve sonradan eşitleme gerekir.
• Bildirimler iPhone kullanıcıları için de kritikse: ana ekrana ekleme koşuluna güvenmek istemiyorsanız.
• Kullanıcılar sizi önce mağazada arıyorsa: sektörünüzde hizmet zaten uygulama üzerinden alışılmışsa.

İkisi birden gerektiğinde

Birçok ürün sonunda iki arayüze ihtiyaç duyar: müşteriler için bir mobil uygulama, ekibiniz için bir web paneli. Bu durumda sıralamadan çok mimari önemlidir: iş kuralları ve veri, iki istemcinin de konuştuğu tek bir API'de durmalıdır. Özel web uygulaması geliştirme işlerinde API öncelikli tasarımı bu yüzden standart kabul ediyoruz; mobil uygulama sonradan eklendiğinde aynı kuralları yeniden yazmak gerekmez. Abonelikle satılan bir ürün kuruyorsanız, genellikle web'le başlamak ve mobil uygulamayı ödeme yapan kullanıcıların talebiyle eklemek daha güvenli bir sıralamadır; bu konuyu SaaS platform geliştirme sayfasında da ele alıyoruz. Hangi arayüzün önce yapılacağına, ilk sürümde hangi kullanıcının ve hangi işin en kritik olduğuna bakarak karar verin.

Mobil uygulama ve web uygulaması maliyetini ne belirler?

Bu yazıda fiyat aralığı vermiyoruz, çünkü kaynağını gösteremeyeceğimiz bir aralık size bir şey söylemez; aynı başlıklı iki proje kapsamına göre çok farklı tutabilir. Bunun yerine maliyeti ve süreyi hangi kalemlerin büyüttüğünü listeliyoruz. Her kalem için yapılacak test aynıdır: teklifte ayrı bir satır olarak yazılmış mı, yazılmamışsa hangi varsayımla fiyatlanmış? Tekliflerin nasıl okunacağını yazılım yaptırma maliyeti ve teklif karşılaştırma rehberimizde ayrıntılı anlattık.

• Platform sayısı: Web, iOS ve Android'in her biri tasarım, test ve yayın yükü ekler. Cross-platform kod tekrarını azaltır ama iki mağaza hazırlığını ve iki cihaz ailesinde testi ortadan kaldırmaz.
• Cihaz özellikleri ve entegrasyonlar: Kamera, ödeme, harita ve mevcut ERP ya da CRM bağlantıları her biri ayrı iş ve ayrı test demektir.
• Çevrimdışı çalışma: Eşitleme ve çakışma kuralları planlamada kolayca hafife alınır.
• Mağaza hazırlığı ve yaşam döngüsü: Ekran görüntüleri, gizlilik bildirimleri, inceleme turları ve yeni işletim sistemi sürümleriyle gelen uyumluluk güncellemeleri.
• Yönetim paneli: Mobil uygulamanın arkasında içerik ve kullanıcıları yönetmek için çoğu zaman bir web paneli de gerekir ve bu parça tekliflerde kolayca atlanır.

Bir de daha temel bir soru var: belki hiç geliştirme yapmanız gerekmiyordur. İşinizi gören hazır bir ürün varsa, onu yapılandırmak çoğu zaman sıfırdan bir uygulamadan daha ucuz ve hızlıdır. Bu kararı özel yazılım mı hazır yazılım mı yazımızda kriterleriyle ele aldık.

Geliştirmeye başlamadan önce kontrol listesi

Aşağıdaki listeyi bir yazılım firmasıyla görüşmeden önce doldurun. Cevaplayamadığınız maddeler, kapsamın henüz hazır olmadığını gösterir; bu durumda ilk adım geliştirme değil, kısa bir keşif ve kapsam çalışmasıdır.

1. İlk sürümün birincil kullanıcısını ve bu kullanıcının en sık yapacağı tek işi bir cümleyle yazın.
2. Kullanıcıların bugün hangi cihazlardan geldiğini ölçün: mevcut sitenizin analitik verisi, destek kayıtları ya da birkaç müşteri görüşmesi yeterlidir.
3. Gereken cihaz özelliklerini "olmazsa olmaz" ve "sonra" diye ikiye ayırın.
4. Çevrimdışı ihtiyacı netleştirin: hangi işlem bağlantısız yapılmalı, iki kişi aynı kaydı değiştirirse hangisi geçerli olur?
5. Bildirimlerin ürün için kritik olup olmadığını ve kullanıcılarınızın ne kadarının iPhone kullandığını yazın.
6. Müşterilerin sizi nasıl bulduğunu yazın: arama, mağaza, satış ekibi ya da davet.
7. Apple ve Google geliştirici hesaplarının şirketiniz adına açılmasını ve kimin yöneteceğini planlayın.
8. Lansman tarihini, mağaza incelemesini ve Google'ın kapalı test şartını hesaba katarak belirleyin.
9. Web ve mobilin aynı API'yi paylaşacağını, kaynak kodun ve hesapların size ait olacağını ve destek döneminin süresini sözleşmede yazılı isteyin.

Mobil uygulama ve web uygulaması kararında sık yapılan hatalar

Aşağıdaki hatalar belirli bir şirkete değil, bu karar verilirken sık görülen genel kalıplara dair. Çoğu, teknolojiden önce kullanıcıyı ve dağıtımı düşünmemekten kaynaklanır.

• Önce uygulamayı yapıp kullanıcıyı sonra aramak: Mağazada olmak, kimsenin sizi bulacağı anlamına gelmez; dağıtım planı olmayan bir uygulama indirilmez.
• Web sitesini uygulama kabuğuna sarmak: Kullanıcıya yeni bir şey sunmaz ve Apple'ın 4.2 maddesine takılma riski taşır.
• Web uygulamasında telefonu sonraya bırakmak: Masaüstü için tasarlanıp sonradan sıkıştırılan ekranlar, telefondan gelen kullanıcıyı kaybettirir.
• iPhone'da PWA bildirimlerine güvenmek: Kullanıcı ana ekrana eklemezse bildirim hiç gitmez.
• Eski uygulama sürümlerini unutmak: Sunucu tarafındaki bir değişiklik, güncelleme yapmamış kullanıcıların uygulamasını bozabilir.
• Web tarafında teknik SEO'yu atlamak: Sayfalar indekslenmezse web'le başlamanın en önemli avantajını kaybedersiniz; nelere bakılacağını Next.js SEO teknik kontrol listesinde topladık.

Biz olsak ne yapardık?

Tipik bir durumu düşünelim: müşterilerine bir hizmet sunan ve bunu bir operasyon ekibiyle yürüten bir şirket, hem bir müşteri uygulaması hem de bir yönetim paneli istiyor ama hangisiyle başlayacağından emin değil. Biz önce 30–45 dakikalık bir keşif görüşmesi yapar, kullanıcıyı, cihazı ve en kritik işi yazıya dökerdik. Ürünün özü bir cihaz özelliğine bağlı değilse, ilk sürüm olarak telefonda da iyi çalışan, API öncelikli bir web uygulaması önerirdik; tekrar kullanım yüksekse ana ekrana eklenebilen bir PWA katmanı eklerdik. Kamera, çevrimdışı saha işi ya da günlük bildirim ihtiyacı netleştiğinde aynı API'nin üzerine React Native ve Expo ile mobil uygulamayı kurar, yalnızca gereken parçada native Swift ya da Kotlin kullanırdık.

Süreç tarafında da değişmeyen birkaç kuralımız var. Keşif aşaması yazılı bir kapsam, teslim planı ve sabit fiyatla biter; kapsam sonradan değişirse değişiklik geliştirilmeden önce fiyatlanır. Kod yazılmadan önce tıklanabilir ekranlar ve teknik plan üzerinde birlikte karar verilir, geliştirme ise her biri test ortamında açıp deneyebileceğiniz çalışan bir sürümle biten iki haftalık döngülerle ilerler. Kod deposu, bulut hesapları ve Apple ile Google geliştirici hesapları ilk günden şirketiniz adına açılır ve sizinle konuşan, kodu yazan ekibin kendisidir. Proje dokümantasyon, bir devir toplantısı ve süresi yazılı olarak belirlenmiş bir destek dönemiyle biter.

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

Her platform sorusu bir geliştirme projesi gerektirmez. Aşağıdaki durumlarda bütçenizi başka bir yere ayırmanızı öneririz.

• Hazır bir no-code araç ya da hazır bir PWA çözümü yetiyorsa: Ekibiniz için basit bir form, onay ya da kayıt akışı arıyorsanız, hazır no-code araçlar, bunların sunduğu ana ekrana eklenebilir web uygulamaları ya da mevcut web sitenizin mobil uyumlu hâle getirilmesi çoğu zaman yeterlidir ve bir ajans projesinden çok daha ucuzdur.
• Kapsam çok küçükse: Tek ekranlı bir kampanya sayfası ya da birkaç günlük bir düzeltme için bir serbest geliştirici ya da mevcut ajansınız daha ekonomik olur.
• İçeride yeterli bir ekibiniz varsa: Web ve mobil tarafını bilen bir ekibiniz ve zamanı varsa, dışarıdan ekip eklemek koordinasyon maliyeti getirir; bu yazıdaki kontrol listesi kararınız için yeterli olabilir.
• Önce birini iyi yapmaya hazır değilseniz: Bütçe tek platforma yetiyor ama ilk sürümde hem web hem iOS hem Android isteniyorsa, iki platformu yarım yapmak yerine kapsamı daraltmak gerekir; bu kararı vermeden başlayan bir proje kimseye yaramaz.

Kendi ürününüz için bu soruları birlikte cevaplamak isterseniz iletişim sayfasından bize yazabilirsiniz; ilk görüşmede yukarıdaki kontrol listesinin üzerinden geçer, ardından problemi nasıl anladığımızı yazılı bir özetle paylaşırız.