Sıkça Sorulan Sorular

Web uygulaması geliştirme, mobil uygulama geliştirme, backend ve API geliştirme, UI/UX tasarım, MVP geliştirme ve kurumsal web sitesi geliştirme hizmetleri sunuyoruz.

Projeleri fikir aşamasından yayına kadar uçtan uca yürütüyoruz: keşif, veri modeli ve mimari, arayüz tasarımı, geliştirme sprintleri, test ve yayın. Her aşamada aynı ekip sahada olduğu için tasarım ile geliştirme arasında devir kaybı yaşanmıyor.

Bazı müşteriler yalnızca tek bir kalem için geliyor — mevcut tasarımın geliştirilmesi ya da mevcut ürünün yeniden tasarlanması gibi. Mevcut ekibinize takım genişletme modeliyle destek vermek de mümkün.

Evet, üç farklı modelde çalışabiliyoruz.

Mevcut tasarımınız varsa yalnızca geliştirme üstlenebiliriz; bu durumda tasarımı geliştirme öncesi uygulanabilirlik açısından gözden geçiriyoruz. Mevcut bir ürününüz varsa yalnızca UI/UX tasarım için çalışabiliriz; teslimat geliştirmeye hazır Figma dosyaları, tasarım sistemi ve tıklanabilir prototip olur.

Üçüncü model takım genişletme: mevcut ekibinize belirli bir süre için geliştirici veya tasarımcı ekliyoruz. Bu modelde ekibinizin süreçlerine ve araçlarına uyum sağlıyoruz.

Ankara, Türkiye merkezliyiz ve hizmet alanı işletmesi olarak çalışıyoruz.

Ankara içindeki projelerde ilk keşif toplantısını yüz yüze yapmayı tercih ediyoruz; bir projenin ilk haftasında alınan kararlar sonradan değiştirilmesi en pahalı olanlar, o yüzden aynı odada olmanın değeri yüksek. Sonraki süreç uzaktan yürüyor.

İstanbul, İzmir ve Türkiye'nin diğer şehirlerindeki müşterilerle, ayrıca yurt dışındaki müşterilerle tamamen uzaktan çalışıyoruz. Türkiye içindeki tüm müşterilerimizle aynı saat dilimindeyiz; bir soruya cevap almak için ertesi günü beklemek gerekmiyor.

Kaynak kodun tamamı ve ürünün fikri mülkiyeti size ait. Kod, ilk günden itibaren sizin adınıza açılmış bir depoda tutuluyor; biz o depoya katkı veren ekip olarak çalışıyoruz.

Teslimat yalnızca kod dosyası değil: mimari kararların yazılı olduğu bir doküman, ortam değişkenlerinin listesi, veritabanı şeması ve yayın adımları da devrediliyor. Amaç, projeyi bizsiz de sürdürebilecek durumda bırakmak.

Tasarım dosyaları (Figma), mağaza hesapları ve alan adı da sizin adınıza açılır. Hiçbir varlık bizim hesabımızda kilitli kalmaz — bu, ajans değiştirmek istediğinizde karşılaşılan en yaygın sorundur ve baştan engellenmesi gerekir.

Teknik SEO'yu ayrı bir hizmet olarak değil, kurumsal web projelerinin standart parçası olarak kuruyoruz. Sunucu tarafında üretilmiş HTML, tek H1, doğru başlık hiyerarşisi, canonical, hreflang, sitemap, robots.txt ve yapılandırılmış veri (schema.org) her teslimatta yer alır.

Bunun üzerine yapay zeka arama motorları için ek bir katman ekliyoruz: llms.txt dosyası, AI tarayıcılara açık robots kuralları ve alıntılanabilir formatta SSS blokları. Kendi sitemizde de aynı kurulumu kullanıyoruz.

İçerik üretimi, anahtar kelime araştırması ve bağlantı çalışması gibi süregelen SEO işleri ayrı bir kapsamdır; talep edilirse aylık çalışma olarak planlıyoruz. Teknik kurulum ile içerik çalışmasını ayırmak, hangi işin ne getirdiğini ölçebilmek için önemli.

Tek doğrulanabilir akışa sahip bir MVP tipik olarak 4-6 hafta içinde yayına alınır. DrapeAI'nin AI destekli sanal deneme uygulamasını bu sürede mağazaya çıkardık.

Süreç 1-2 haftalık sprint döngüleriyle ilerler ve her sprint sonunda test cihazına kurulabilen, çalışan bir sürüm teslim edilir. Böylece ilerlemeyi rapor üzerinden değil, ürünün kendisi üzerinden görürsünüz.

Bu süre ekibi büyüterek değil, kapsamı daraltarak kazanılır. İlk toplantıda MVP dışında kalacak özellikleri yazılı bir listeye alıyoruz; kapsamın sessizce büyümesini engelleyen en pratik araç bu. Birden fazla ana akış içeren projelerde gerçekçi süre 8-12 haftadır.

Her proje altı adımda ilerliyor: keşif, mimari ve veri modeli, arayüz tasarımı, geliştirme sprintleri, test ve yayın. Adımlar birbirinin üstüne biniyor — tasarım devam ederken veri modeli çoktan kurulmuş oluyor.

Keşif aşamasında iş hedefini, kullanıcı akışlarını ve mevcut sistemleri çıkarıyoruz; çıktısı yazılı bir kapsam listesi ve kapsam dışı bırakılanların listesi oluyor. Mimari aşamasında veri modeli, yetkilendirme kuralları ve dış entegrasyonlar netleşiyor; bu iki adım toplam sürenin yaklaşık beşte birini alıyor ve sonradan en pahalı düzeltmeleri önlüyor.

Geliştirme 1-2 haftalık sprintlerle yürüyor. Her sprint sonunda çalışan bir sürüm görüyorsunuz. Yayın adımı mağaza gönderimi veya sunucu kurulumunun yanı sıra analitik, hata izleme ve yedekleme kurulumunu da kapsıyor.

Üç sabit temas noktası var: ortak bir mesajlaşma kanalı, sprint sonu demo ve her zaman erişilebilir bir test sürümü.

Mesajlaşma kanalı günlük sorular için; bir konu 12 saatten uzun cevapsız kalmıyor. Sprint sonu demoda çalışan sürümü birlikte geziyoruz ve bir sonraki sprintin kapsamını orada karara bağlıyoruz. Mobil projelerde TestFlight veya Firebase App Distribution üzerinden, web projelerinde önizleme adresi üzerinden ürüne istediğiniz an erişebiliyorsunuz.

Yazılı takip için görev panosu (issue listesi) ortak: hangi işin hangi durumda olduğunu bize sormadan görebiliyorsunuz. Ayrı bir haftalık rapor hazırlamıyoruz; çalışan ürünün kendisi rapordan daha doğru bilgi veriyor.

Kapsam değişikliği istisna değil, normal. Önemli olan değişikliğin süre ve bütçeye etkisinin görünür olması.

Yeni bir istek geldiğinde onu iki soruyla değerlendiriyoruz: bu özellik yayını geciktirir mi, ve yayından sonra eklenmesi daha mı pahalı olur? Cevap ikisinde de hayırsa istek yayın sonrası listeye gidiyor. Evetse, aynı sprintte hangi işin çıkacağını birlikte belirliyoruz — kapsam eklemek her zaman bir takas.

Sabit kapsamlı sözleşmelerde bu tür eklemeler yazılı bir ek kapsam kalemi olarak fiyatlanıyor. Sprint bazlı çalışmada ise doğrudan sonraki sprintin planına giriyor, ayrıca bir sözleşme değişikliği gerekmiyor. Her iki durumda da tahmini etki, iş başlamadan önce yazılı olarak paylaşılıyor.

İletişim formundan gelen taleplere en geç 12 saat içinde dönüş yapıyoruz.

İlk dönüşte genellikle birkaç netleştirici soru soruyoruz: projenin hangi problemi çözeceği, hedef platformlar ve varsa mevcut sistemler. Ardından kısa bir keşif görüşmesi planlıyoruz.

Keşif görüşmesinin sonunda kapsam, gerçekçi bir süre tahmini ve bütçe aralığı netleşmiş oluyor. Bu aşamaya kadar herhangi bir ücret talep edilmiyor.

Maliyeti belirleyen ana etken ekran sayısı değil, entegrasyon sayısı ve kullanıcı rolü karmaşıklığıdır. Uygulamanın bağlanacağı her dış sistem (ödeme, ERP, kargo, harita) ayrı bir geliştirme ve test kalemidir.

Bunun yanında hedef platform sayısı, çevrimdışı çalışma ihtiyacı, gerçek zamanlı özellikler ve tasarımın sıfırdan mı yapılacağı bütçeyi doğrudan etkiler.

Kısa bir keşif görüşmesinin ardından iki model sunuyoruz: kapsamı net projeler için sabit kapsamlı teklif, kapsamın gelişeceği projeler için sprint bazlı çalışma. Tipik bütçe aralıklarını blog yazımızda proje tipine göre tablo halinde paylaşıyoruz.

Ödeme tek seferde değil, teslim edilen işe bağlı kilometre taşlarıyla yapılıyor. Tipik kurulum, proje başlangıcında bir başlangıç ödemesi, ara teslimlerde iki veya üç ara ödeme ve yayında son ödeme şeklinde.

Her kilometre taşı somut bir çıktıya bağlı: tasarım onayı, ilk çalışan sürüm, mağaza gönderimi gibi. Ödeme takvimi süreye değil teslimata bağlandığı için, gecikme olduğunda risk tek tarafta kalmıyor.

Keşif görüşmesi ve teklif hazırlığı ücretsiz. Sprint bazlı çalışan projelerde ise faturalama tamamlanan sprint üzerinden aylık yapılıyor; istediğiniz sprint sonunda çalışmayı durdurma hakkınız saklı kalıyor.

Kapsamı baştan netleşebilen projelerde sabit fiyat daha uygun: kurumsal web sitesi, tanımlı bir iç panel, mevcut tasarımın geliştirilmesi gibi. Bu modelde toplam bedel ve teslim tarihi baştan bellidir, karşılığında kapsam da yazılı olarak sabitlenir.

Ürünün kendisi henüz doğrulanmamışsa — yeni bir uygulama fikri, kullanıcı geri bildirimine göre yön değiştirecek bir MVP — sprint bazlı çalışma daha ekonomik oluyor. Sabit fiyat bu tür projelerde belirsizlik payını en baştan bütçeye ekler; sprint modelinde ise yalnızca gerçekten yapılan iş ödenir.

Uygulamada birçok proje ikisini birleştiriyor: ilk faz (keşif ve tasarım) sabit fiyatla, geliştirme fazı sprint bazlı. Hangi modelin sizin için uygun olduğunu keşif görüşmesinin sonunda birlikte belirliyoruz.

Frontend tarafında React, Next.js, TypeScript ve Tailwind CSS; mobilde Flutter ve Dart; backend tarafında .NET, C#, Python ve PostgreSQL kullanıyoruz.

Teknoloji seçimini projeye göre yapıyoruz. İçeriğin arama motorlarında bulunması gerekiyorsa statik üretim veya sunucu tarafı render; giriş sonrası kullanılan bir panelse istemci tarafı render yeterli oluyor. Mobilde arayüz ve iş mantığı ağırlıklı uygulamalarda Flutter tercih ediyoruz; yoğun donanım erişimi gerektiren senaryolarda native geliştirmeyi değerlendiriyoruz.

TypeScript'i istisnasız kullanıyoruz. Tip güvenliği ilk ayda değil, kod tabanı büyüdüğünde fark yaratıyor ve bakım maliyetini düşüren en pratik tek karar.

Evet, iki farklı şekilde. Birincisi hazır model API'lerini (görüntü işleme, metin üretimi, sınıflandırma) ürüne bağlamak; ikincisi bu çağrıların etrafındaki ürün mantığını — kuyruk, önbellek, maliyet sınırı ve hata durumları — kurmak.

DrapeAI'de kullanıcının fotoğrafı üzerinde kıyafet denemesini sağlayan görüntü işleme akışını, Trendela'da ise portföy verisini yorumlayan analiz katmanını bu şekilde kurduk. İkisinde de asıl iş modelin kendisi değil, model çağrısının yavaş veya hatalı olduğu durumda kullanıcının ne göreceğiydi.

Yapay zeka özelliği eklerken ilk sorumuz şu oluyor: bu özellik olmadan ürün işe yarıyor mu? Cevap hayırsa, model bağımlılığı ürünün en kırılgan noktası haline gelir ve buna göre yedek akış tasarlamak gerekir.

Evet. Sistemin bir API'si varsa doğrudan bağlanıyoruz; yoksa veri aktarımı için ara bir katman kuruyoruz — zamanlanmış dosya aktarımı veya veritabanı üzerinden okuma gibi.

Entegrasyonlarda süreyi belirleyen şey bizim tarafımız değil, karşı sistemin dokümantasyonu ve test ortamı oluyor. Test ortamı olan bir sisteme bağlanmak birkaç gün sürerken, dokümante edilmemiş ve yalnızca canlı ortamı olan bir sistem haftalar alabiliyor. Bu yüzden keşif aşamasında entegrasyon yapılacak her sistemin dokümantasyonunu ve erişim bilgilerini önden istiyoruz.

Entegrasyonlar hata toleransıyla kurulur: karşı sistem yanıt vermediğinde işlem kaybolmaz, kuyruğa alınır ve yeniden denenir. Kurumsal projelerde en sık yaşanan sorun bu yedeklemenin baştan düşünülmemiş olmasıdır.

Evet, mağaza gönderim sürecinin tamamını biz yürütüyoruz: uygulama kimliği ve sertifikaların hazırlanması, mağaza görselleri ve açıklama metinleri, gizlilik politikası bağlantısı, yaş sınırı ve veri toplama beyanları.

Hesaplar sizin adınıza açılır — Apple Developer Program ve Google Play Console üyelikleri şirketinizin adına kayıtlı olur, biz geliştirici olarak eklenip çalışırız. Bu ayrım önemli: uygulama sizin hesabınızda olduğu sürece yorumlar, indirme verisi ve gelecekteki güncellemeler üzerindeki kontrol sizde kalır.

İlk gönderimde Apple tarafında inceleme genelde birkaç gün sürüyor ve ilk denemede ret alınması olağandır; ret gerekçesini karşılayıp yeniden gönderme işi de kapsama dahil. Planlamada yayın tarihinden en az bir hafta önce ilk gönderimi yapacak şekilde takvim kuruyoruz.

Evet. Yayın sonrası hata giderme, performans iyileştirme, yeni özellik geliştirme ve altyapı bakımı için sürekli destek anlaşmaları yapıyoruz.

Bakım bütçesi için yaygın yaklaşım, geliştirme bedelinin yıllık %15-20'si arasında bir tutar ayırmaktır. Bu, hem kütüphane güncellemelerini hem de mağaza gerekliliklerindeki değişiklikleri karşılar.

Destek anlaşması yapmak zorunlu değil. Kaynak kodun tamamı sizin deponuzda kaldığı ve mimari dokümantasyonu teslim edildiği için, projeyi kendi ekibinizle veya başka bir ekiple sürdürmeniz mümkün.