Yazan
Emre Sarıyıldız
Kısa cevap: Kurumsal mobil uygulama yaptırmadan önce iş hedefi, kullanıcı rolleri, ekranlar, entegrasyonlar, veri güvenliği, mağaza hesapları, test planı ve bakım sorumluluğu yazılı hale getirilmelidir. Yalnızca “iOS ve Android uygulama istiyoruz” demek sağlıklı teklif almak için yeterli değildir.
Kurumsal bir mobil uygulama; saha ekibinin görev takibi, bayi siparişi, müşteri portalı, randevu, satış ekibi, stok, servis, onay veya sadakat süreçlerinden birini telefona taşıyabilir. Her ekranın gerçek bir kullanıcı ihtiyacına dayanması gerekir. Bu rehber, kurumsal mobil uygulama veya “mobil app yaptırmak istiyorum” araması yapan işletmeler için proje başlamadan önce kullanılabilecek kapsamlı bir gereksinim listesidir.
Son güncelleme: 17 Temmuz 2026. İçerik, YellowStar Design yazılım ve dijital deneyim ekibi tarafından hazırlanmıştır.
Kurumsal mobil uygulama nedir?
Kurumsal mobil uygulama, bir şirketin çalışan, bayi, tedarikçi veya müşterilerinin belirli iş süreçlerini mobil cihazdan yürütmesini sağlayan yazılımdır. Tüketici uygulamalarından farklı olarak rol ve yetki, mevcut sistemlerle entegrasyon, veri güvenliği, kayıt izleme ve operasyonel süreklilik daha belirleyici olabilir.
Örneğin bir saha servis uygulamasında görev atama, konum, fotoğraf, imza ve çevrimdışı çalışma gerekirken; bayi uygulamasında ürün, stok, fiyat listesi, sipariş, cari hesap ve onay akışı öne çıkar. Aynı “mobil uygulama” başlığı altında olsalar da mimari ve test ihtiyaçları birbirinden farklıdır.
Özet: Kurumsal mobil proje, ekran tasarlama işi değil; iş sürecini, veriyi, yetkiyi ve mobil kullanım koşullarını birlikte çözme işidir.
Önce mobil uygulamaya gerçekten ihtiyaç var mı?
Her iş problemi uygulama mağazasından indirilen bir uygulama gerektirmez. Kullanıcı seyrek giriş yapıyorsa, cihaz özelliklerine ihtiyaç yoksa veya süreç ağırlıklı olarak masaüstünde yürüyorsa responsive web paneli daha verimli olabilir. Düzenli saha kullanımı, bildirim, kamera, konum, biyometri veya çevrimdışı işlem gerekiyorsa mobil uygulama daha anlamlı hale gelir.
| İhtiyaç | Öncelikli çözüm adayı | Karar sorusu |
|---|---|---|
| Seyrek kullanılan bilgi ve form | Mobil uyumlu web | Kullanıcı uygulamayı telefonda tutar mı? |
| Hızlı pilot ve sınırlı cihaz özelliği | PWA | Mağaza dağıtımı veya yoğun çevrimdışı kullanım gerekiyor mu? |
| iOS ve Android müşteri uygulaması | Çapraz platform veya native | Donanım ve performans gereksinimi nedir? |
| Saha, depo veya satış ekibi | Kurumsal mobil uygulama | Çevrimdışı işlem ve cihaz yönetimi gerekiyor mu? |
| İç süreç ve onay | Web paneli + mobil uygulama | Yönetici ile saha çalışanı aynı arayüzü mü kullanacak? |
Karar aşamasında Adana mobil uygulama geliştirme hizmet sayfamızdaki yaklaşım ve özel web yazılım seçenekleri birlikte değerlendirilebilir.
Gereksinim dokümanı neden hazırlanmalı?
Gereksinim dokümanı, işletmenin ne istediğini ve yazılım ekibinin ne teslim edeceğini ortak dile çevirir. Belge çok uzun olmak zorunda değildir; ancak kullanıcıların kim olduğu, hangi işlemleri yapacağı, hangi sistemlere bağlanılacağı ve başarının nasıl ölçüleceği açık olmalıdır.
Belirsiz kapsam; tekliflerin karşılaştırılamamasına, sonradan ek maliyete, yanlış teknoloji seçimine ve teslim tartışmasına yol açabilir. “Bildirim olacak” yerine bildirimin kim tarafından, hangi olayla, hangi kullanıcıya, hangi izinle ve hangi ekrana gönderileceği tarif edilmelidir.
1. İş hedefi ve başarı ölçütleri
Uygulamanın çözeceği tek cümlelik problem
Proje, “Şirketimizin mobil uygulaması olsun” cümlesiyle değil, ölçülebilir bir problemle başlamalıdır. Örnek: saha teknisyeninin görev ve servis formunu çevrimdışı tamamlaması, bayinin güncel stoktan sipariş vermesi veya müşterinin randevu ve ödeme sürecini tek kanalda yürütmesi.
Başarıyı gösteren olaylar
İndirme sayısından önce tamamlanan görev, verilen sipariş, azalan manuel veri girişi, tamamlanan randevu veya çözülen destek talebi gibi iş olayları tanımlanır. Mevcut başlangıç değeri varsa kayıt altına alınır; yoksa ilk sürüm ölçüm dönemi olarak planlanır.
2. Kullanıcı, rol ve yetki matrisi
Kurumsal uygulamalarda herkes aynı ekranı görmez. Çalışan, yönetici, bayi, müşteri, saha personeli ve sistem yöneticisinin yetkileri ayrı olmalıdır. Yetki yalnızca menüyü gizlemek değildir; sunucu tarafında hangi veriye ve işleme erişilebileceğini de sınırlar.
| Rol | Görebileceği veri | Yapabileceği işlem |
|---|---|---|
| Saha personeli | Kendisine atanan görevler | Durum, fotoğraf, form ve imza ekleme |
| Bölge yöneticisi | Bölgesindeki ekip ve görevler | Atama, onay ve rapor görüntüleme |
| Bayi | Kendi fiyat, stok ve siparişleri | Sipariş, talep ve cari hareket inceleme |
| Müşteri | Kendi hesap ve talepleri | Randevu, ödeme veya destek talebi |
| Sistem yöneticisi | Yetkisi kapsamındaki kayıtlar | Rol, kural, içerik ve entegrasyon yönetimi |
3. Kullanıcı yolculukları ve ekran listesi
Ekran listesi, kullanıcı yolculuklarından çıkarılmalıdır. Kullanıcının uygulamayı açmasından hedef işlemi tamamlamasına kadar geçen adımlar çizilir. Hata, iptal, bağlantı kesilmesi ve yetkisiz işlem gibi alternatif akışlar da ana senaryo kadar önemlidir.
- Kayıt, davet veya kurumsal hesapla giriş
- Şifre yenileme, çok faktörlü doğrulama ve cihaz değişimi
- Ana panel ve role göre özet
- Liste, arama, filtre ve detay ekranları
- Form, dosya, fotoğraf, imza veya barkod işlemleri
- Onay, ret, iade ve açıklama akışları
- Bildirim ve görev merkezi
- Profil, izin, gizlilik ve hesap silme
- Yardım, hata bildirimi ve destek
4. Native, çapraz platform veya PWA seçimi
Teknoloji seçimi yalnızca ilk geliştirme maliyetine göre yapılmamalıdır. Kamera, Bluetooth, NFC, arka plan işlemi, yoğun çevrimdışı kullanım, performans, animasyon, kurumsal cihaz yönetimi ve ekip yetkinliği birlikte değerlendirilir.
| Yaklaşım | Uygun olduğu durum | Değerlendirme noktası |
|---|---|---|
| Native iOS/Android | Platforma özel yoğun donanım ve performans ihtiyacı | İki ayrı kod tabanı ve ekip maliyeti |
| Flutter/React Native gibi çapraz platform | Ortak iş akışına sahip iOS ve Android uygulamaları | Kullanılan eklenti ve native modüllerin sürdürülebilirliği |
| PWA | Hızlı dağıtım, form ve içerik ağırlıklı süreçler | Cihaz özelliği, mağaza ve çevrimdışı sınırları |
| WebView ağırlıklı hibrit | Mevcut web sistemini kontrollü biçimde mobil kabuğa alma | Performans, mağaza politikası ve kullanıcı deneyimi |
Teknoloji kararı için kesin reçete yoktur. Gereksinimler yazıldıktan sonra mimari seçeneklerin artı ve eksi yönleri karşılaştırılmalıdır.
5. Veri, API ve entegrasyon gereksinimleri
Kurumsal mobil uygulama genellikle tek başına çalışmaz. ERP, CRM, stok, muhasebe, ödeme, kimlik, harita, belge yönetimi veya mevcut web servislerine bağlanır. Entegrasyon dokümanı yoksa teknik keşif aşaması planlanmalıdır.
Her entegrasyon için sorulacak sorular
- API dokümanı, test ortamı ve teknik sorumlu var mı?
- Kimlik doğrulama ve erişim anahtarları nasıl yönetiliyor?
- İstek sınırı, zaman aşımı ve hata kodları tanımlı mı?
- Veri gerçek zamanlı mı, belirli aralıkla mı güncellenecek?
- İşlem tekrarlanırsa çift kayıt nasıl önlenecek?
- Bağlantı kesildiğinde kuyruk ve yeniden deneme kuralı nedir?
- Test verisi kişisel veya ticari hassas bilgi içeriyor mu?
- API değişikliğinde bildirim ve sürüm politikası var mı?
ERP ve CRM bağlantısı proje için merkeziyse kurumsal yazılım ve entegrasyon kapsamı ayrıca ele alınmalıdır.
6. Çevrimdışı çalışma ve senkronizasyon
Saha, depo veya üretim ortamında bağlantı her zaman güvenilir olmayabilir. Uygulamanın bağlantı yokken hangi işlemleri yapacağı açıkça yazılmalıdır. Sadece ekranın açılması değil; veri kaydetme, dosya yükleme, sıra yönetimi ve bağlantı geldiğinde çakışma çözümü planlanır.
Örneğin aynı iş emri hem telefonda hem merkezde güncellenirse hangi kayıt geçerli olacaktır? Kullanıcıya çakışma gösterilecek mi, zaman damgası mı kullanılacak, yönetici onayı mı gerekecek? Bu kararlar sonradan eklenen teknik ayrıntılar değil, iş kuralıdır.
7. Kimlik doğrulama ve kurumsal erişim
Kullanıcı türüne göre e-posta/parola, SMS doğrulama, tek kullanımlık bağlantı, SSO, kurumsal dizin veya çok faktörlü doğrulama kullanılabilir. Yetkili personel işten ayrıldığında hesabın nasıl kapatılacağı ve cihazdaki oturumun nasıl sonlandırılacağı da süreçte yer almalıdır.
- Parola ve oturum süresi politikası
- Başarısız giriş ve hesap kilitleme
- Yeni cihaz ve şüpheli oturum bildirimi
- Rol değişikliğinin uygulamaya yansıması
- Kayıp cihazda uzaktan oturum sonlandırma
- Yönetici işlemleri için kayıt ve denetim izi
8. Güvenlik ve gizlilik gereksinimleri
OWASP MASVS, mobil uygulama güvenliği için güvenli veri saklama, kriptografi, kimlik doğrulama, ağ iletişimi, platform etkileşimi, kod ve gizlilik kontrol grupları sunar. Her projede bütün kontroller aynı seviyede uygulanmayabilir; risk ve veri türüne göre güvenlik profili belirlenmelidir.
Google Play Data Safety ve Apple App Privacy alanları, uygulamanın ve eklenen üçüncü taraf SDK’ların veri toplama ve paylaşma davranışlarına göre doldurulur. Bu nedenle analitik, hata izleme, bildirim, harita, reklam ve giriş servisleri daha proje başında veri envanterine eklenmelidir.
Minimum güvenlik soruları
- Cihazda hangi hassas veriler saklanacak?
- Veri aktarımı şifreli bağlantı üzerinden mi yapılacak?
- Yetki kontrolü yalnızca uygulamada mı, sunucuda da mı uygulanıyor?
- Log kayıtlarında parola, token veya kişisel veri bulunuyor mu?
- Uygulama tersine mühendislik ve değiştirilmiş cihaz riskine karşı ne yapacak?
- Hesap silme ve veri talebi hangi kanaldan yürütülecek?
9. Performans ve kullanılabilirlik
“Hızlı çalışacak” ölçülebilir bir gereksinim değildir. Kritik ekranların hedef açılış süresi, kabul edilebilir API yanıtı, dosya boyutu, düşük bağlantı davranışı ve desteklenen işletim sistemi sürümleri tanımlanmalıdır. Liste ve rapor ekranlarında binlerce kaydın nasıl sayfalanacağı planlanır.
Erişilebilirlik de tasarımın bir parçasıdır. Metin büyütme, renk kontrastı, dokunma alanları, ekran okuyucu etiketleri ve yalnızca renge bağlı olmayan durum göstergeleri proje kapsamına uygun şekilde test edilir.
10. Prototip ve tasarım sistemi
Kodlama başlamadan önce ana kullanıcı yolculukları tıklanabilir prototipte doğrulanmalıdır. Prototip, gereksiz ekranları erken fark ettirir ve iş birimiyle yazılım ekibi arasındaki yanlış anlamayı azaltır. Tasarım sistemi; renk, tipografi, buton, form, hata, boş durum ve yükleme davranışlarını tutarlı hale getirir.
11. MVP ve sürüm yol haritası
MVP, işletmenin ana problemini çözen ve gerçek kullanıcıyla test edilebilen en küçük bütünlüklü sürümdür. “Az özellikli kötü ürün” değildir. Olmazsa olmaz iş akışı, güvenlik, hata yönetimi ve ölçüm MVP içinde yer alır; rapor çeşitleri veya ikincil modüller sonraki sürüme bırakılabilir.
| Öncelik | Tanım | Örnek |
|---|---|---|
| Olmazsa olmaz | Ana işlem tamamlanmadan ürün değer üretmez | Görev görüntüleme ve servis formu |
| Olmalı | İlk sürümü güçlendirir, geçici yöntemle yönetilebilir | Gelişmiş filtre ve dışa aktarma |
| Olabilir | Değerli ama doğrulanması gereken fikir | Rozet, oyunlaştırma veya öneri |
| Şimdilik kapsam dışı | Sonraki sürüm için kayda alınır | Çok ülke ve çok para birimi |
12. Test planı
Kurumsal mobil uygulama yalnızca geliştiricinin telefonunda test edilmemelidir. Farklı ekran boyutları, işletim sistemi sürümleri, düşük bağlantı, yetki rolleri ve gerçek iş verisine benzeyen test senaryoları gerekir.
- Fonksiyon ve kabul testleri
- Rol ve yetki testleri
- API, zaman aşımı ve hata senaryoları
- Çevrimdışı çalışma ve senkronizasyon
- Performans ve yoğun veri
- Bildirim, derin bağlantı ve izinler
- Güvenlik kontrolleri
- Erişilebilirlik ve kullanılabilirlik
- App Store ve Google Play yayın paketleri
- Pilot kullanıcı kabul testi
13. Mağaza hesapları ve fikrî varlık sahipliği
Apple Developer ve Google Play Console hesaplarının işletme adına açılması uzun vadede daha sağlıklıdır. Alan adı, sunucu, kaynak kodu erişimi, tasarım dosyaları, imzalama anahtarları, mağaza kayıtları, analitik hesapları ve üçüncü taraf servislerin sahipliği sözleşmede belirtilmelidir.
Teslim yalnızca uygulama dosyasından ibaret değildir. Kurulum dokümanı, ortam değişkenleri, API belgeleri, sürüm notları, yönetim paneli kullanıcıları ve yedekleme prosedürü de devir paketine dahil olabilir.
14. Bakım, destek ve sürüm yönetimi
iOS ve Android işletim sistemleri, uygulama mağazası kuralları ve kullanılan SDK’lar zaman içinde değişir. Bakım planı; hata düzeltme, uyumluluk güncellemesi, güvenlik yaması, izleme, yedekleme ve yeni özellik geliştirmeyi birbirinden ayırmalıdır.
- Kritik ve normal hata tanımları
- Yanıt ve çözüm hedefleri
- Mesai dışı destek kapsamı
- Sunucu, veritabanı ve bildirim izleme
- Mağaza sürüm takvimi
- Yedekleme ve geri dönüş testi
- Yeni isteklerin tahmin ve onay süreci
Yayın sonrası işletim planı için teknik destek ve bakım kapsamı proje sözleşmesinden önce netleştirilebilir.
Kurumsal mobil uygulama maliyetini neler belirler?
Fiyatı yalnızca ekran sayısı belirlemez. Platform, entegrasyon, çevrimdışı çalışma, kullanıcı rolleri, güvenlik, yönetim paneli, özel tasarım, veri aktarımı, test cihazları, mağaza süreci ve bakım kapsamı birlikte değerlendirilir. Hazır API’si olan bir sistemle, eski bir ERP’ye özel bağlantı kurulması aynı iş değildir.
| Maliyet kalemi | Neden değişir? | Teklifte nasıl yazılmalı? |
|---|---|---|
| Analiz ve UX | Rol ve iş akışı sayısı | Teslim edilecek akış ve prototipler |
| Mobil geliştirme | Platform ve cihaz özelliği | Desteklenen platform/sürümler |
| Backend ve panel | Veri modeli, rol ve raporlar | Modül ve API kapsamı |
| Entegrasyon | Doküman ve test ortamının kalitesi | Bağlanılacak sistem ve veri yönü |
| Güvenlik ve test | Veri riski ve doğrulama seviyesi | Test türleri ve kabul kriteri |
| Bakım | İzleme, yanıt süresi ve sürüm sıklığı | Aylık kapsam ve hariç işler |
Temsili kurumsal uygulama senaryoları
Not: Aşağıdaki senaryolar gerçek müşteri sonucu veya performans iddiası değildir. Gereksinimlerin nasıl ayrıştığını göstermek için hazırlanmıştır.
Saha servis uygulaması
Sorun: Teknisyen görevleri mesajlaşma uygulamasından alıyor, servis formları sonradan sisteme giriliyor. Çözüm yaklaşımı: görev, çevrimdışı form, fotoğraf, imza, konum ve merkez paneli. Kritik gereksinim: senkronizasyon ve yetki. Ölçüm: tamamlanan görev, eksik form ve senkronizasyon hatası.
Bayi sipariş uygulaması
Sorun: Fiyat ve stok bilgileri farklı dosyalardan paylaşılıyor. Çözüm yaklaşımı: bayiye özel katalog, stok, fiyat, sipariş ve onay. Kritik gereksinim: ERP API’si ve veri güncelliği. Ölçüm: mobil sipariş, hatalı ürün ve onay süresi.
Kurumsal iç onay uygulaması
Sorun: İzin, satın alma ve masraf talepleri e-posta zincirlerinde bekliyor. Çözüm yaklaşımı: rol bazlı talep, onay, bildirim ve denetim kaydı. Kritik gereksinim: SSO, yetki matrisi ve işlem izi. Ölçüm: tamamlanan talep ve bekleme aşaması.
Teklif almadan önce 30 maddelik kontrol listesi
- Uygulamanın çözeceği iş problemi tek cümleyle yazıldı.
- Başarı ölçütleri ve başlangıç verisi belirlendi.
- Kullanıcı grupları ve cihaz koşulları listelendi.
- Rol ve yetki matrisi hazırlandı.
- Ana kullanıcı yolculukları çizildi.
- Hata, iptal ve bağlantı kesilme senaryoları yazıldı.
- MVP ile sonraki sürümler ayrıldı.
- iOS, Android, PWA veya web kararı gerekçelendirildi.
- Desteklenecek işletim sistemi sürümleri belirlendi.
- Çevrimdışı çalışacak ekranlar listelendi.
- Entegrasyon yapılacak sistemler belirlendi.
- API dokümanı ve test ortamı doğrulandı.
- Veri modeli ve kayıt sahipliği kararlaştırıldı.
- Kimlik doğrulama yöntemi seçildi.
- SSO ve çok faktörlü doğrulama ihtiyacı değerlendirildi.
- Toplanan kişisel ve ticari veriler listelendi.
- Gizlilik, izin ve hesap silme akışları tanımlandı.
- Üçüncü taraf SDK envanteri planlandı.
- Güvenlik kontrol ve test seviyesi belirlendi.
- Performans ve yanıt hedefleri yazıldı.
- Erişilebilirlik gereksinimleri eklendi.
- Tıklanabilir prototip ve onay süreci planlandı.
- Test cihazları ve kullanıcı kabul grubu belirlendi.
- Analitik olayları ve hata izleme planlandı.
- Apple ve Google geliştirici hesabı sahipliği kararlaştırıldı.
- Kaynak kodu, tasarım ve anahtar devir koşulları yazıldı.
- Sunucu, yedekleme ve izleme sorumlusu belirlendi.
- Bakım ve destek kapsamı tanımlandı.
- Kabul kriterleri ve teslim belgeleri listelendi.
- Tekliflerin aynı kapsam üzerinden karşılaştırılması sağlandı.
Sıkça sorulan sorular
Kurumsal mobil uygulama ne işe yarar?
Çalışan, bayi, müşteri veya saha ekiplerinin belirli iş süreçlerini telefondan güvenli ve izlenebilir biçimde yürütmesini sağlar.
Mobil uygulama mı, mobil uyumlu web sitesi mi yaptırmalıyız?
Seyrek kullanım ve form/içerik ağırlıklı ihtiyaçta web çözümü yeterli olabilir. Bildirim, kamera, konum, çevrimdışı kullanım veya düzenli işlem gerekiyorsa mobil uygulama değerlendirilir.
Kurumsal uygulama hem iOS hem Android çalışabilir mi?
Evet. İki ayrı native uygulama veya uygun projelerde çapraz platform teknoloji kullanılabilir. Karar donanım, performans, bütçe ve bakım hedeflerine göre verilir.
Mobil uygulama mevcut ERP veya CRM’e bağlanabilir mi?
Sistem güvenli API, web servis veya uygun veri aktarım yöntemi sunuyorsa entegrasyon yapılabilir. Doküman, test ortamı ve veri kuralları önceden incelenmelidir.
Kurumsal mobil uygulama çevrimdışı çalışabilir mi?
Evet; fakat hangi verinin cihazda tutulacağı, bağlantı geldiğinde nasıl eşitleneceği ve çakışmanın nasıl çözüleceği özel olarak tasarlanmalıdır.
Uygulama yaptırmak ne kadar sürer?
Süre; kullanıcı rolleri, ekranlar, entegrasyonlar, çevrimdışı çalışma, güvenlik, test ve mağaza süreçlerine bağlıdır. Analiz tamamlanmadan güvenilir süre verilemez.
Kurumsal mobil uygulama fiyatı nasıl belirlenir?
Platform, özel tasarım, backend, yönetim paneli, entegrasyon, güvenlik, veri aktarımı, test ve bakım kapsamı maliyeti belirler. Aynı ekran sayısına sahip iki proje farklı teknik zorlukta olabilir.
Kaynak kodu ve mağaza hesapları kime ait olmalı?
Sahiplik ve kullanım hakları sözleşmede açıkça yazılmalıdır. Geliştirici mağaza hesapları, alan adı ve temel servis hesaplarının işletme adına açılması önerilir.
Uygulama yayınlandıktan sonra bakım gerekir mi?
Evet. İşletim sistemi ve mağaza değişiklikleri, güvenlik yamaları, SDK güncellemeleri, hata izleme ve yeni ihtiyaçlar için bakım planı gerekir.
Uygulama güvenliği nasıl kontrol edilir?
Risk modeline göre kod, kimlik doğrulama, veri saklama, ağ iletişimi, yetki ve gizlilik kontrolleri uygulanır. OWASP MASVS ve ilgili test rehberleri kontrol temeli olarak kullanılabilir.
İlk sürümde bütün özellikler olmalı mı?
Hayır. Ana problemi çözen bütünlüklü MVP hazırlanmalı; ikincil raporlar ve doğrulanmamış özellikler gerçek kullanım verisine göre sonraki sürümlere alınmalıdır.
YellowStar Design proje öncesi analiz yapıyor mu?
İhtiyaca göre iş hedefi, kullanıcı rolleri, ekran akışları, entegrasyonlar, teknik mimari ve sürüm planı için keşif ve kapsam çalışması yapılabilir.
Resmî ve teknik kaynaklar
- OWASP Mobile Application Security Verification Standard
- Google Play Data Safety açıklamaları
- Apple App Store Connect gizlilik yönetimi
- Apple App Review Guidelines
- Firebase Cloud Messaging belgeleri
Kurumsal mobil uygulama projenizin kapsamını netleştirelim
YellowStar Design, mobil projeyi özellik listesine göre değil; iş süreci, kullanıcı, entegrasyon, güvenlik ve sürdürülebilirlik üzerinden planlar. Mevcut sisteminizi ve hedefinizi paylaşarak analiz görüşmesi oluşturmak için iletişim sayfamızı kullanabilirsiniz. Kurumsal yaklaşımımızı hakkımızda, çalışmalarımızı ise referanslarımız sayfasında inceleyebilirsiniz.