AI destekli mobil uygulamalar pazarda görünür. Fakat iş sonucunda çoğu zaman görünmez kalır. Sorun genellikle modelin zekâsı değil, ürünün bütünü içinde nereye ve nasıl yerleştirildiğidir.
Türkiye tarafında tablo sert. Bi Technology analizine göre Türkiye'deki şirketlerin %95'i AI yatırımlarından ölçülebilir finansal getiri elde edemiyor ve temel neden teknoloji eksikliği değil; stratejik hatalar, veri altyapısı sorunları ve kurumsal adaptasyon eksiklikleri (Bi Technology analizi). Yani “ai destekli mobil uygulamalar neden beklenen etkiyi yaratmıyor?” sorusunun cevabı, tek bir teknik arızada değil; strateji, veri, mimari, UX ve işletme modeli arasındaki kırılmalarda yatıyor.
En kritik nokta şu. Mobilde AI özelliği eklemek, ürün değeri üretmekle aynı şey değil. Bir özetleme motoru, öneri sistemi, chatbot veya görsel analiz modülü koyabilirsiniz. Ama bu özellik kullanıcı akışını hızlandırmıyor, karar kalitesini yükseltmiyor ya da operasyonu sadeleştirmiyorsa, uygulama sadece daha pahalı bir yazılım hâline gelir.
Giriş: Potansiyel ve Gerçeklik Arasındaki Uçurum
Küresel tarafta AI uygulamaları büyüyor. Yerel tarafta ise çok sayıda proje beklenen etkiyi yaratamıyor.

Sensor Tower’ın State of Mobile raporuna göre, 2025 projeksiyonunda AI uygulamaları küresel harcamada 85 milyar dolara ve kullanımda 48 milyar saate ulaşıyor; buna karşılık Türkiye’de firmaların organizasyonel uyumsuzluklar nedeniyle bu potansiyelden yeterince yararlanamadığı ve performanslarının %70’e varan oranlarda düştüğü aktarılıyor (Webtekno’nun aktardığı rapor özeti).
Bu çelişki yüzeyde bir pazar problemi gibi görünür. Aslında daha derin bir yürütme problemidir. Küresel pazarda talep vardır, kullanıcı alışkanlığı oluşmaktadır ve AI tabanlı deneyimler normalleşmektedir. Buna rağmen yerel projeler canlıya geçtiğinde kullanıcı davranışı, operasyon akışı ve gelir modeli arasında tutarlı bir bağ kuramaz.
Yanlış soru nerede başlıyor
Şirketler çoğu zaman şu soruyla yola çıkıyor: “Uygulamaya AI nerede eklenebilir?”
Daha doğru soru şudur: “Kullanıcının hangi işi bugün gereksiz sürtünmeyle tamamlanıyor?”
Bu ayrım küçük görünür ama sonucu belirler. İlk yaklaşım teknoloji merkezlidir. İkinci yaklaşım ise iş sonucu merkezlidir.
Potansiyelin değere dönüşmediği an
Bir mobil ürünün başarısız olduğu an çoğu zaman lansman günü değildir. Ondan önce gelir. Ürün ekibi, veri ekibi ve yönetim aynı başarı tanımında buluşamadığında proje zaten kırılmaya başlamıştır.
AI destekli mobil projelerde en pahalı hata, yanlış model seçimi değil; değeri hangi kullanıcı davranışında ölçeceğini baştan tanımlamamaktır.
Türkiye’deki örnekler bize aynı kalıbı gösteriyor. Uygulama mağazada yer alıyor, demolar etkileyici görünüyor, pilotta olumlu geri bildirim geliyor. Fakat ölçek aşamasında iş hedefiyle teknik gerçeklik birbirine uymuyor. Sonuçta yatırım var, görünür yenilik var, fakat kalıcı etki yok.
Stratejik Hatalar ve Yanlış Beklenti Yönetimi
Birçok AI destekli mobil uygulama, ilk teknik hatadan önce yanlış iş kurgusu nedeniyle zayıflar. Sorun genelde model seçimi değildir. Sorun, ürünün hangi davranışı değiştireceğinin ve bu değişimin hangi finansal sonuca bağlanacağının baştan tanımlanmamasıdır.

Türkiye’de tekrarlanan kalıp açık. Yönetim ekibi “uygulamaya AI ekleme” kararını yenilik göstergesi olarak görüyor. Ürün ekibi bunu bir özellik listesine çeviriyor. Geliştirme tarafı da modeli uygulamaya bağlamaya odaklanıyor. Fakat kullanıcı açısından temel görev aynı kalıyor. Sipariş vermek, doğru ürünü bulmak, destek almak veya form doldurmak hâlâ zahmetliyse, AI katmanı iş sonucunu değil yalnızca maliyeti büyütüyor.
İlk kırılma noktası: trendi ürün stratejisi sanmak
Pek çok mobil projede başlangıç sorusu hatalı kuruluyor: “AI’ı nereye koyabiliriz?” Bu soru teknoloji merkezlidir ve ekibi gösterişli demolar üretmeye iter. Daha doğru soru şudur: “Kullanıcının hangi işi yavaş, hatalı veya gereğinden pahalı ilerliyor?”
Aradaki fark doğrudan ROI’ye yansır. Örneğin bir e-ticaret uygulamasında sohbet tabanlı öneri alanı eklemek tek başına iş değeri üretmez. Değer, arama süresi kısalırsa, yanlış ürün görüntüleme oranı düşerse, sepet tamamlama oranı artarsa oluşur. Aksi durumda ekip bir AI özelliği yayınlamış olur, şirket ise performansı artmayan bir edinim ve elde tutma problemiyle baş başa kalır.
İkinci kırılma noktası: başarıyı model metriğiyle karıştırmak
Burada en sık görülen yönetim hatası, teknik doğruluğu ticari başarı yerine koymaktır. Modelin yanıt kalitesi yüksek olabilir. Kullanıcı yine de görevi tamamlamıyorsa ürün başarısızdır.
Bu ayrımı net kurmayan ekipler, yanlış panolara bakar:
Model metriği: doğruluk, latency, token maliyeti, yanıt tutarlılığı
Ürün metriği: görev tamamlama oranı, destek talebinde azalma, dönüşüm oranı, churn değişimi
İş metriği: birim ekonomi, müşteri edinim maliyeti geri dönüşü, kullanıcı başına gelir, operasyonel verim
Sorun bu üç katmanın birbirine bağlanmamasıdır. Kullanıcının sorusuna daha iyi yanıt veren bir model, destek merkezine gelen çağrıyı azaltmıyorsa veya satış dönüşümünü artırmıyorsa ticari karşılığı sınırlı kalır. Yönetim “çalışıyor” der, bilanço “etki sınırlı” der.
Üçüncü kırılma noktası: AI özelliğini gelir modelinden bağımsız tasarlamak
Mobil ürünlerde AI çoğu zaman maliyet yaratan bir katman olarak devreye girer. Sunucu maliyeti artar, denetim ihtiyacı doğar, içerik ve destek süreçleri karmaşıklaşır. Buna karşılık gelir tarafında hangi mekanizmanın güçleneceği net değilse yatırımın geri dönüşü gecikir.
Bu yüzden AI kararı, ürün ekonomisiyle birlikte ele alınmalıdır. Abonelik mi güçlenecek, işlem başına gelir mi artacak, destek maliyeti mi düşecek, premium kullanım mı oluşacak? Bu sorular cevaplanmadan geliştirilen özellikler yüksek kullanım alsa bile kârlılık üretmeyebilir. Bu değerlendirme için mobil uygulama üzerinden para kazanma stratejileri ve gelir modelleri çerçevesi faydalı bir referans sunar.
Beklenti yönetimi neden projeyi ya kurtarır ya da bozar
AI projeleri şirket içinde sık sık “hızlı etki” vaadiyle konumlanıyor. Bu dil iki sonucu beraberinde getiriyor. İlki, pilot başarılarının ölçeklenebilir ürün başarısı sanılması. İkincisi, ekiplerin öğrenme ve iterasyon için ihtiyaç duyduğu zamanın ortadan kalkması.
Daha sağlıklı yaklaşım, beklentiyi sınırlı ama ölçülebilir bir iş sonucuna bağlamaktır:
| Beklenti alanı | Zayıf yaklaşım | Sağlıklı yaklaşım |
|---|---|---|
| Problem tanımı | Uygulamaya akıllı asistan eklemek | Belirli bir akışta sürtünmeyi azaltmak |
| Lansman planı | Geniş kapsamlı ilk sürüm | Dar kapsamlı pilot ve kontrollü yayılım |
| Başarı ölçümü | Model kaliteli görünüyor | Kullanıcı davranışı ve finansal sonuç iyileşiyor |
| Yönetim anlatısı | AI büyümeyi hızlandıracak | AI belirli bir darboğazı iyileştirecek |
Buradaki kritik nokta şudur. Beklenti ne kadar muğlaksa hayal kırıklığı o kadar hızlı gelir. Çünkü AI, kötü tanımlanmış bir ürünü tek başına iyi ürüne çeviremez.
Pratik kural: AI özelliğini ayrı bir vitrin projesi gibi değil, tek bir kullanıcı işini daha hızlı, daha doğru veya daha düşük maliyetle tamamlayan ürün bileşeni olarak tasarlayın.
Stratejik hata genelde aynı cümlede görünür. Şirket “AI yayına alındı” diye rapor verir. Kullanıcı ise aynı işi tamamlamak için hâlâ fazla adım atar. İşte düşük benimseme, yüksek churn ve zayıf ROI çoğu zaman bu kopuştan çıkar.
Teknik Engeller ve Mimari Yetersizlikler
Strateji doğru olsa bile zayıf mimari projeyi durdurur. Özellikle mobil ürünlerde AI’nin sahadaki davranışı, demo ortamındaki davranışından çok farklıdır.

Newyorkbex raporuna göre, Türkiye’deki AI projelerinin canlıya geçişteki en büyük engelleri entegrasyon boşlukları ve operasyonel karmaşıklık. Aynı rapor, Apple’ın App Store Kılavuzu 2.5.2 gibi kuralların geliştiricilerin %70’ini etkileyen bir risk oluşturduğunu ve mobil cihaz üzerinde dinamik AI geliştirmeyi kısıtladığını belirtiyor (Newyorkbex raporu).
Pilot cehennemi nasıl oluşur
Pilot aşamada her şey kontrollüdür. Veri daha temizdir. Kullanıcı sayısı sınırlıdır. Operasyon ekibi projeye özel ilgi gösterir.
Canlı ortamda ise denge bozulur:
Gerçek veri gelir: Eksik, tutarsız, farklı formatlarda veri modeli zorlar.
Uç durumlar görünür: Kullanıcılar beklenmeyen komutlar ve akışlar üretir.
Mobil kısıtlar devreye girer: Ağ gecikmesi, cihaz farkları, pil tüketimi ve eski işletim sistemi sürümleri deneyimi bozar.
Birçok ekip modeli doğru kurduğunu sanır. Aslında uygulama ile model arasındaki taşıma katmanı zayıftır. API gecikmesi, hata yönetimi, geri dönüş mantığı ve önbellekleme stratejisi iyi tasarlanmadığında AI özelliği “çalışıyor” görünür ama güven vermeyen bir deneyim üretir.
Mimari kararların ertelenmesi pahalıdır
Aşağıdaki kararlar başta verilmezse proje sonradan ağırlaşır:
| Mimari alan | Yanlış yaklaşım | Sonuç |
|---|---|---|
| Backend tasarımı | AI çağrılarını mevcut servislerin üstüne rastgele eklemek | Gecikme ve izlenebilirlik sorunu |
| Veri akışı | Kaynak sistemleri sonradan bağlamak | Tutarsız bağlam |
| Hata toleransı | Model cevap vermezse ne olacağını tanımlamamak | Kopan kullanıcı akışı |
| Mobil istemci | Tüm zekâyı cihaz üstüne yükleme hayali | Platform kısıtları ve performans sorunu |
Geliştirici gözüyle asıl mesele
Mobil AI projesi, sadece model entegrasyonu değildir. Aynı anda şunları çözmeniz gerekir:
Güvenilir servis orkestrasyonu
İzin ve politika uyumu
Ağ zayıfken bozulmayan kullanıcı akışı
Model başarısız olduğunda anlamlı fallback davranışı
Uygulama zekâ gösterirken kırılmamalı. Kullanıcı, modelin neden başarısız olduğunu anlamak zorunda kalıyorsa mimari görevini yapmamış demektir.
Bu yüzden teknik ekiplerin sorması gereken soru “hangi model daha iyi?” değil, “hangi mimari bu özelliği istikrarlı şekilde taşıyabilir?” olmalı.
Veri Kalitesi ve Gizlilik Sorunlarının Etkisi
AI projelerinde en sık gözden kaçan gerçek basittir. Model, verinin kalitesi kadar iyidir. Mobilde bu gerçek daha sert hissedilir çünkü uygulama, kullanıcının günlük davranışını doğrudan etkiler.
Türkiye bağlamında sorun sadece veri eksikliği değildir. Sorun, verinin dağınık, bağlamsız ve yönetişimsiz olmasıdır. Müşteri verisi bir sistemde, işlem geçmişi başka bir sistemde, destek kayıtları üçüncü bir yerde durduğunda model teknik olarak çalışsa bile iş açısından eksik karar verir.
Çöp veri, pahalı hata
Bir öneri sistemi düşünün. Kullanıcının geçmiş davranışı eksikse sistem alakasız öneriler üretir. Bir finans uygulamasında risk skoru bağlamsızsa kullanıcı yanlış yönlendirilmiş hisseder. Bir sağlık veya eğitim uygulamasında özetleme motoru yanlış öncelik verirse güven hızla zedelenir.
Buradaki kayıp yalnızca performans kaybı değildir. Marka güveni de zayıflar. Çünkü kullanıcı teknik hata ile kurumsal ciddiyetsizliği ayırmaz. Uygulama yanlışsa, marka da güvensiz görünür.
Veri yönetişimi ürün kararının parçasıdır
AI özelliği geliştiren ekiplerin şu soruları erken sorması gerekir:
Hangi veriyi gerçekten kullanma hakkımız var
Bu veri hangi amaç için toplanmıştı
Kullanıcı bu işleme açık biçimde ne kadar görünürlükle onay verdi
Model çıktısı itiraz edilebilir mi
Yanlış veya eski veri nasıl düzeltilecek
Bu sorular hukuk ekibine en sonda devredilecek maddeler değildir. Bunlar ürün tasarımının kendisidir.
Gizlilik, fren değil tasarım disiplini
KVKK ve GDPR uyumu çoğu ekipte “yayına çıkmadan önce kontrol edilecek liste” gibi ele alınıyor. Bu yaklaşım sorun yaratır. Çünkü gizlilik yükümlülükleri en sona bırakıldığında veri akışını, loglama biçimini, izin ekranlarını ve üçüncü taraf servis kullanımını geriye dönük düzeltmek gerekir.
Daha sağlam yaklaşım privacy by design mantığıdır. Yani veri minimizasyonu, açık rıza, erişim sınırlandırma, denetlenebilirlik ve silme süreçleri ürün tasarımının ilk sürümünde yer alır.
Veri gizliliği regülasyon konusu olduğu kadar ürün güveni konusudur. Kullanıcı, neden veri verdiğini ve bunun karşılığında ne kazandığını anlamak ister.
AI destekli mobil uygulamalar neden beklenen etkiyi yaratmıyor sorusunun sık cevabı burada gizlidir. Şirketler modeli kurar ama veri zeminini kurmaz. Sonuçta ortaya akıllı görünen, fakat güven vermeyen bir deneyim çıkar.
Kullanıcı Deneyimi ve Adaptasyon Problemleri
Kullanıcı gözünden bakınca başarısız AI uygulamaları birbirine çok benzer. Özellik vardır ama rahatlık yoktur. Hız vardır ama açıklık yoktur. Sonuç vardır ama güven yoktur.

Kötü deneyimin tipik hikâyesi
Bir kullanıcı finans uygulamasına giriyor. Uygulama ona “senin için kişiselleştirilmiş öneri” sunuyor. Ama önerinin neden çıktığını açıklamıyor. Kullanıcı, öneriyi kabul ederse ne olacağını anlamıyor. İtiraz edecek, düzenleyecek ya da geri alacak bir yol da bulamıyor.
Teknik olarak AI özelliği vardır. Ürün olarak güvenli bir deneyim yoktur.
Bu yüzden AI projelerinde terk edilme sebebi çoğu zaman model kalitesi değil, açıklanabilirlik eksikliği ve akış sürtünmesi olur.
İyi deneyim görünmez çalışır
Başarılı AI deneyimi kendini “ben AI’yım” diye bağırarak göstermez. Kullanıcının işini daha kısa adımda, daha az zihinsel yükle bitirmesine yardım eder.
İyi bir örnek şunları yapar:
Kullanıcının niyetini tahmin eder ama dayatmaz.
Öneri sunar ama gerekçe de verir.
Hata yaptığında sessizce çökmez, anlaşılır alternatif sunar.
Kullanıcıya kontrol hissini bırakır.
Bu nedenle AI özellikleri için klasik arayüz ilkeleri daha da önemlidir. Özellikle açıklama katmanı, geri bildirim mekanizmaları, iptal edilebilirlik ve durum görünürlüğü. Bu çerçeveyi uygulama arayüzü açısından değerlendirmek isteyen ekipler için kullanıcı dostu mobil arayüz UI UX tasarımı nasıl olmalı yaklaşımı faydalı bir referans sağlar.
Güven, teknik değil deneyimsel bir sonuçtur
Aynı AI motoru iki uygulamada bambaşka etki yaratabilir. Farkı arayüz kararları belirler.
| Deneyim unsuru | Zayıf uygulama | Güçlü uygulama |
|---|---|---|
| Öneri açıklaması | “Sizin için önerildi” | Kısa ve anlaşılır gerekçe |
| Kullanıcı kontrolü | Kabul et ya da çık | Düzenle, reddet, geri al |
| Hata anı | Sessiz başarısızlık | Net durum mesajı ve alternatif yol |
| Öğrenme döngüsü | Geri bildirim yok | “Bu yararlı mıydı?” gibi basit sinyal toplama |
Kullanıcı AI’ya değil, hissettiği sonuca tepki verir. Sonuç belirsizse güven oluşmaz.
Adaptasyon probleminin ikinci boyutu kurum içidir. Satış, destek ve operasyon ekipleri yeni AI davranışını anlamadığında kullanıcıya tutarlı açıklama yapamaz. Böylece UX sorunu sadece ekranda değil, bütün müşteri yolculuğunda büyür.
Başarıya Giden Yol Haritası ve Eyleme Geçirilebilir Kontrol Listesi
AI destekli mobil ürünlerde sonuç getiren unsur, model kalitesi kadar uygulama disiplini. Başarılı ekipler AI’yı “ek bir özellik” gibi değil, gelir, maliyet, kullanıcı tutma ve operasyon yükü üzerinde etkisi ölçülebilen bir ürün sistemi olarak yönetiyor.
Bu nedenle yol haritası, teknoloji seçimiyle değil iş hedefiyle başlamalıdır. Önce şu bağlantıyı kurun: Hangi kullanıcı problemi çözülecek, bu problem hangi metriği etkileyecek, o metriğin finansal karşılığı ne olacak? Bu zincir kurulmadığında ekip çıktı üretir, şirket sonuç göremez.
Önce dar kapsamlı değer tanımı yapın
İlk sürümün görevi geniş görünmek değil, net değer üretmektir.
“Destek süreçlerini AI ile dönüştürmek” yön vermez. “İlk destek talebinde yanlış yönlendirmeyi azaltmak” ise veri ihtiyacını, başarı metriğini ve test senaryolarını netleştirir. Böyle bir tanım yapıldığında ekip şu üç metriği baştan izleyebilir: doğru yönlendirme oranı, ilk temas çözüm oranı ve destek ekibine eskalasyon hacmi.
Dar kapsam, teknik riski de düşürür. Modelin başarısı, sınırlı bir akışta gerçek kullanıcı davranışıyla sınanır. Başarısızlık durumunda zarar kontrollü kalır, öğrenme hızı artar.
MVP’yi arayüz demolarına indirgemeyin
AI projelerinde MVP çoğu zaman yanlış tanımlanıyor. Ekranlar çalışıyor olabilir, fakat üretim ortamında değer üretmek için gereken yapı kurulmamışsa ortada ürün değil, demo vardır.
AI projeleri de, fikir aşamasından yayına kadar adım adım mobil yazılım geliştirme sürecinde olduğu gibi, fikirden yayına kadar uçtan uca planlama ister. Bu planın MVP içinde yer alması gereken parçaları şunlardır:
Veri kaynağı ve veri sahipliği: Hangi veri kullanılacak, kim yönetecek, ne sıklıkla güncellenecek?
İzin ve gizlilik akışı: Kullanıcıdan hangi onay alınacak, veri nerede işlenecek, kayıtlar nasıl tutulacak?
Fallback senaryosu: Model hata verdiğinde, geciktiğinde veya düşük güven skoruyla sonuç ürettiğinde kullanıcı ne görecek?
Gözlemlenebilirlik: Hangi istek başarısız oldu, neden oldu, hangi cihazlarda veya akışlarda yoğunlaştı?
İterasyon planı: Lansman sonrası hangi sinyallerle model, prompt, arayüz veya iş kuralı güncellenecek?
Bu başlıklar yoksa proje teknik olarak yayına çıkabilir, fakat ticari olarak yönetilemez.
AI Mobil Uygulama Başarı Kontrol Listesi
| Aşama | Kritik Eylem | Başarı Metriği |
|---|---|---|
| Problem tanımı | AI eklemek yerine çözülecek kullanıcı işini netleştirin | Görev tanımının ekipler arasında aynı anlaşılması |
| MVP kurgusu | Tek akış, tek hipotez, tek ana başarı metriği ile başlayın | Hipotezin belirli bir zaman aralığında test edilebilir olması |
| Veri hazırlığı | Veri temizliği, etiketleme, bağlam eşleme ve izin kontrolünü birlikte ele alın | Tutarlı çıktı üreten kullanılabilir veri akışı |
| Mimari tasarım | API, backend, model çağrıları, loglama ve fallback yapısını baştan kurun | Hata oranı ve yanıt süresinin kabul edilebilir aralıkta kalması |
| Gizlilik | KVKK ve gerekiyorsa GDPR gerekliliklerini ürün akışına yerleştirin | Denetlenebilir izin kayıtları ve veri işleme süreçleri |
| UX tasarımı | Açıklama, geri alma, düzenleme ve alternatif yol seçenekleri ekleyin | Görev tamamlama oranı ve kullanıcı güven sinyalleri |
| Test süreci | Uç durumları, düşük kalite girdileri ve entegrasyon kopmalarını test edin | Yayın öncesi kritik kırılma noktalarının bulunması |
| Lansman sonrası | Crash analizi, kullanıcı geri bildirimi, model performansı ve mağaza yorumlarını birlikte izleyin | Kullanıcı tutma, memnuniyet ve operasyon yükünde iyileşme |
Uygulama liderleri için karar çerçevesi
Yayına alma kararı, “model çalışıyor mu” sorusuna indirgenmemeli. Daha doğru çerçeve şudur:
Bu özellik hangi kullanıcı işini daha hızlı, daha doğru veya daha düşük maliyetle tamamlatıyor?
Başarıyı hangi iş metriğinde göreceğiz? Gelir, dönüşüm, çözüm süresi, elde tutma veya destek maliyeti?
Model, entegrasyon veya veri akışı bozulursa kullanıcı deneyimi nasıl korunacak?
Veri kullanımını kullanıcıya açık, anlaşılır ve güven veren biçimde anlatabiliyor muyuz?
Bu dört soru, projeyi aynı anda ürün, mühendislik, hukuk ve operasyon açısından test eder. Cevaplar net değilse sorun genellikle modelde değil, ürün tanımındadır.
En yüksek etkiyi yaratan AI mobil ürünleri, en fazla özellik barındıranlar değil, işletmesi en öngörülebilir olanlardır. Türkiye pazarında bu fark daha da belirgindir. KVKK uyumu, cihaz çeşitliliği, bağlantı kalitesi, kullanıcı güven eşiği ve destek beklentileri birlikte düşünülmeden geliştirilen uygulamalar, teknik olarak çalışsa bile beklenen iş sonucunu üretmez.
Sonuç açık. AI’yı ürünün üstüne ekleyen ekipler deneme yapar. AI’yı veri, mimari, deneyim ve operasyon kararlarının içine yerleştiren ekipler ise ölçülebilir değer üretir.
AI destekli mobil uygulama fikrini gerçek bir ürüne dönüştürmek, özellikle Türkiye pazarında strateji, mimari, KVKK uyumu ve mobil kullanıcı deneyimini birlikte ele almayı gerektirir. Bu alanlarda deneyimli bir geliştirme ortağı arıyorsanız, İpek Yazılım’ın yaklaşımını inceleyebilirsiniz: https://ipekyazilim.com

