Bir mobil uygulamanın geliştirme süresini ve bütçesini ekran sayısından çok; uygulamanın çevrim dışı (offline) çalışıp çalışmayacağı, mevcut ERP veya CRM sistemleriyle çift yönlü veri senkronizasyonu, kullanıcı rolleri arasındaki yetki sınırları ve mağaza (App Store ve Google Play) güvenlik/onay gereksinimleri belirler. 2026 itibarıyla kurumsal bir mobil uygulama projesini doğru planlamanın yolu, tek bir paket fiyatı aramak yerine projeyi keşif, kavram kanıtlama (PoC), ilk canlı sürüm (MVP) ve ölçekleme fazlarına ayırmaktır. Projenizin kendi parametrelerine göre hafta ve ekip kırılımını görmek için ücretsiz yazılım kapsam ve MVP süre hesaplayıcımızı kullanabilirsiniz.
Neden sabit fiyat listeleri kurumsal projelerde yanıltıcıdır?
İnternetteki hazır fiyat tabloları genellikle birbirinin kopyası olan katalog uygulamalarını baz alır. Oysa gerçek bir operasyonda çalışan saha satış uygulaması, bayi sipariş portalı veya hasta takip sistemi arka planda yaşayan bir veritabanına, kimlik doğrulama katmanına ve kurumsal iş kurallarına bağlanır.
İki uygulama dışarıdan bakıldığında aynı sayıda ekrana sahip görünebilir. Ancak birincisi yalnızca sunucudan ürün listesi çekerken, ikincisi internetin çekmediği bir depoda barkod okutup yerel veritabanına kayıt yazıyor ve bağlantı geldiğinde SAP veya Logo ERP ile çakışma çözerek (conflict resolution) senkronize oluyorsa, ikinci projenin mühendislik eforu birincinin birkaç katıdır. Bu nedenle ALGOFACT olarak mobil uygulama geliştirme projelerinde tahmini rakamlar yerine mühendislik kapsamını belirleyen altı somut değişkeni inceleriz.
Kapsam katmanlarına göre tipik faz ve süre matrisi
Aşağıdaki tablo, kurumsal ve girişim projelerinde karşılaştığımız dört ana uygulama tipinin mühendislik fazlarını ve önerilen ekip yapısını özetler:
| Uygulama Katmanı | Tipik Kapsam | Keşif ve Mimari | Geliştirme ve Test | Önerilen Çekirdek Ekip |
|---|---|---|---|---|
| Yalın MVP (Tek Akış) | Tek bir iş problemini doğrulayan 5 ila 8 ekran, standart kimlik doğrulama, temel bildirimler | 1 ila 2 hafta | 4 ila 6 hafta | Çözüm Mimarı, Mobil Mühendisi, Backend Mühendisi |
| Müşteri / Bayi Portalı | Ürün kataloğu, cari hesap, sipariş/ödeme akışı, rol bazlı yetki ve yönetim paneli | 1 ila 2 hafta | 6 ila 10 hafta | Çözüm Mimarı, Mobil Mühendisi, Backend Mühendisi, QA |
| Saha Operasyon Uygulaması | Çevrim dışı (offline) veri kaydı, kamera/barkod/konum kullanımı, görev atama ve senkronizasyon | 2 hafta | 8 ila 12 hafta | Çözüm Mimarı, Kıdemli Mobil Mühendisi, Backend/API Mühendisi, QA |
| ERP / HBYS / AI Entegre Sistem | Kurumsal SSO, çift yönlü ERP/CRM/HBYS bağlantısı, yapay zeka/görüntü işleme ve ISO 27001 denetim izi | 2 ila 3 hafta (PoC dahil) | 10 ila 16 hafta | Çözüm Mimarı, Mobil Ekibi, Backend/Entegrasyon Ekibi, AI/DevOps Mühendisi |
Süreyi ve maliyeti belirleyen 6 mühendislik faktörü
1. Çapraz platform (Cross-Platform) mu, yerel (Native) geliştirme mi?
Kurumsal B2B uygulamaların, müşteri portallarının ve e-ticaret sistemlerinin büyük bölümünde tek kod tabanından hem iOS hem Android çıktısı üreten modern çapraz platform mimarileri (React Native veya Flutter) en doğru mühendislik tercihidir. İş kuralları, ekran tasarımları ve API bağlantıları bir kez yazılır; bakım ve yeni özellik ekleme süresi neredeyse yarıya iner.
Doğrudan donanım seviyesinde düşük gecikmeli Bluetooth/BLE sensör iletişimi, ağır gerçek zamanlı görüntü işleme veya işletim sistemine özgü arka plan servisleri gerektiğinde ise yerel (Swift/Kotlin) modüller devreye alınır. Kararı alışkanlıkla değil, ilk haftadaki mimari incelemede donanım ihtiyaçlarına göre veririz.
2. Backend, API ve mevcut ERP/CRM entegrasyonu
Mobil uygulama buzdağının yalnızca görünen yüzüdür. Uygulamanın hızlı ve güvenli çalışması, arkasındaki API katmanının ve veritabanının kalitesine bağlıdır. Sıfırdan kurulan temiz bir PostgreSQL ve REST/GraphQL API yapısı öngörülebilir bir sürede tamamlanır.
Buna karşılık uygulama şirket içindeki mevcut bir ERP, CRM veya HBYS sistemine bağlanacaksa; karşı sistemin API olgunluğu, yanıt süreleri, hata durumunda yeniden deneme kuyrukları (retry queues) ve veri eşleştirme kuralları takvimin ana belirleyicisi haline gelir. Dokümantasyonu eksik eski sistemlerde tam geliştirmeye başlamadan önce 1 haftalık teknik bir PoC ile veri alışverişini doğrularız.
3. Çevrim dışı (Offline-First) çalışma ve senkronizasyon
Saha servis ekipleri, tarım ve üretim hangarı personeli veya lojistik sürücüleri her zaman kesintisiz internet bağlantısına sahip değildir. Ohalo için geliştirdiğimiz tohum genetiği ve depolama hangarı takip sistemlerinde olduğu gibi, sahadaki kullanıcının bağlantısı koptuğunda da işlem yapabilmesi gerekir.
Çevrim dışı çalışan bir uygulamada veriler cihaz üzerindeki şifreli yerel veritabanında tutulur ve bağlantı sağlandığında sunucuyla eşitlenir. Aynı kaydın hem merkezde hem sahada değiştirildiği durumların nasıl çözüleceği (conflict resolution) baştan tasarlanmalıdır.
4. Kullanıcı rolleri, çoklu organizasyon ve güvenlik (KVKK / ISO 27001)
Tek tip kullanıcının girdiği bir tüketici uygulamasıyla; bölge müdürü, bayi yetkilisi, saha teknisyeni ve son müşterinin farklı ekranlar ve farklı veri sınırları gördüğü bir B2B uygulaması aynı sürede çıkmaz.
Kişisel verilerin veya ticari sırların işlendiği projelerde kurumsal tekli oturum açma (SSO), cihaz üzerinde güvenli anahtar saklama (Keychain/Keystore), hassas işlemler için denetim izi (audit log) ve KVKK ile ISO 27001:2022 uyumluluk kontrolleri veri modelinin içine ilk günden yazılır.
5. Yapay zeka, ses ve görüntü işleme bileşenleri
Mobil uygulama yalnızca form dolduran bir araç olmaktan çıkıp; kamerayla çekilen bir üretim parçasındaki kusuru bulan, faturayı OCR ile okuyan veya sesli komutla randevu/kayıt açan bir asistana dönüştüğünde projeye model değerlendirme ve MLOps adımları eklenir.
Modelin cihaz üzerinde mi (on-device) yoksa sunucuda mı çalışacağı, gecikme süresi (latency) ve doğruluk eşiği MVP geliştirme aşamasında gerçek veri kümesiyle ölçülür.
6. App Store, Google Play ve kurumsal dağıtım (MDM) süreçleri
Uygulamanın kodlanması bitiş çizgisi değildir. Apple App Store ve Google Play Store inceleme süreçleri; hesap doğrulaması (DUNS numarası), gizlilik bildirimleri, hesap silme akışı zorunluluğu ve uygulama içi ödeme kuralları nedeniyle takvimde mutlaka ayrı bir faz olarak yer almalıdır. Yalnızca şirket çalışanlarının kullanacağı iç uygulamalarda ise Apple Business Manager veya Kurumsal Cihaz Yönetimi (MDM) dağıtım hatları kurulur.
Teklif istemeden önce hazırlık kontrol listesi
Bir yazılım ortağıyla görüşmeye oturmadan önce şu altı sorunun yanıtını netleştirmeniz hem teklif süresini kısaltır hem de gereksiz maliyetleri önler:
- Uygulamayı kimler kullanacak (müşteri, bayi, saha personeli, yönetici) ve her rol hangi işlemi tamamlayacak?
- İlk canlı sürümde (MVP) olmazsa olmaz tek ana akış nedir, hangi özellikler ikinci faza bırakılabilir?
- Uygulama hangi mevcut sistemlerle (ERP, CRM, ödeme kuruluşu, e-Fatura) konuşmalı ve bu sistemlerin hazır API dokümantasyonu var mı?
- Kullanıcılar internet bağlantısı olmadan işlem yapmak zorunda mı?
- Cihazın hangi donanım özelliklerine (kamera, barkod okuyucu, GPS, biyometrik giriş, push bildirim) ihtiyaç var?
- Canlıya geçişten sonra kodu ve bulut ortamını kendi ekibiniz mi devralacak, yoksa sürekli bakım anlaşması mı planlanıyor?
ALGOFACT ile süreç nasıl başlar?
Adana (Çukurova) ve Ankara TEKMER’deki mühendislik ofislerimizden Türkiye ve ABD’deki kurumlar için ISO/IEC 27001:2022 standardında web ve mobil sistemler teslim ediyoruz. Süreç 30 dakikalık bir keşif görüşmesiyle başlar; ardından kurucu ekibimiz ekran envanterini, mimariyi, faz planını ve ilk sürüm kapsamını yazılı olarak sunar.
Projenizin tahmini süresini hemen hesaplamak için MVP süre ve kapsam hesaplayıcımızı deneyebilir veya doğrudan iletişim sayfamızdan keşif görüşmesi planlayabilirsiniz.