Kısaca ne bilmelisiniz?
Teknik şartname teknoloji markası seçmekten önce kullanıcı problemini, kritik akışları, veri sorumluluğunu ve kabul kriterlerini aynı dokümanda netleştirmelidir.
Bu rehber kimler için?
- Mobil ürün fikrini MVP’ye dönüştüren girişimler
- iOS, Android veya cross-platform seçen ekipler
- Bütçe ve yayın takvimi hazırlayan karar vericiler
- Mağaza süreçlerini ilk kez yöneten işletmeler
Bu rehberi Codeexia’nın proje deneyimi, resmî kaynaklar ve teklif görüşmelerinde tekrar eden gerçek sorular üzerinden hazırladık. Değişebilen ücret ve teknik koşulları kaynaklarıyla belirtiyor; proje tahminlerini kesin teklif gibi sunmuyoruz.
Teknik şartnamenin amacı geliştiriciye teknoloji dikte etmek değil, farklı firmaların aynı ürüne teklif vermesini sağlamaktır. İyi doküman kullanıcı problemini, kritik akışları, veri sorumluluğunu ve kabul koşullarını açıklar.
Bir sayfalık ürün özetiyle başlayın
Uygulama kimin hangi problemini çözüyor, mevcut alternatif nedir ve ilk sürümün başarı ölçütü ne olacak? Bu üç soruya cevap vermeyen özellik listesi, kapsamı büyütür fakat ürünü netleştirmez.
Kullanıcı rolleri ve akışları
Misafir, üye, yönetici, saha çalışanı veya işletme hesabı gibi rolleri ayırın. Her rol için kayıt, giriş, ana görev, bildirim ve destek akışını yazın. Ekran sayısından önce kullanıcının tamamlayacağı işi tanımlayın.
Backend ve yönetim paneli
- Hangi veriler tutulacak ve kim görebilecek?
- Yönetici hangi kayıtları düzenleyecek?
- Ödeme, harita, CRM veya ERP entegrasyonu var mı?
- Bildirimler hangi olaylarda gönderilecek?
- Raporlama ve dışa aktarma gerekli mi?
Teknoloji kararını nasıl yazmalısınız?
“Flutter kullanılacaktır” demek yerine performans, çevrimdışı çalışma, kamera, konum, Bluetooth veya arka plan işlemi gibi gereksinimleri yazın. Firmadan native ve cross-platform seçeneklerinin etkisini açıklamasını isteyin.
Güvenlik ve kişisel veri
Kimlik doğrulama, rol bazlı yetki, veri şifreleme, loglama, hesap silme ve yedekleme beklentilerini belirtin. KVKK metinleri için hukuki sorumluluğun kimde olacağını, teknik uygulamanın kim tarafından yapılacağını ayırın.
Kabul kriterleri olmadan teslim tamamlanmaz
| Alan | Örnek kabul ölçütü |
|---|---|
| Kayıt | Doğrulama kodu süresi ve hata durumları çalışır |
| Performans | Kritik ekran hedef cihazlarda kabul edilen sürede açılır |
| Yayın | Mağaza formları, görseller ve gizlilik bağlantıları hazırdır |
| Devir | Kod, hesaplar ve kurulum dokümanı teslim edilir |
Teklif ekinde ne isteyin?
Faz planı, ekip rolleri, varsayımlar, kapsam dışı işler, test yaklaşımı, mağaza yayın sorumluluğu, bakım modeli ve ödeme takvimi aynı cevap dosyasında bulunmalıdır.
Teknoloji seçimi için native ve cross-platform karşılaştırmasını okuyabilir veya mobil uygulama proje görüşmesi sayfasında MVP kapsamınızı paylaşabilirsiniz.
Kaynaklar ve doğrulama yöntemi
Değişebilen ücret, politika ve teknik gereksinimler için aşağıdaki resmî kaynaklar kullanılmıştır. Proje aralıkları teklif değil, karşılaştırma yapmayı kolaylaştıran editoryal çerçevedir.
- Apple — Developer program üyelikleri (erişim: 31 Temmuz 2026)
- Apple — App Review Guidelines (erişim: 31 Temmuz 2026)
- Google Play — Developer account registration (erişim: 31 Temmuz 2026)
- Google Play — App setup and review (erişim: 31 Temmuz 2026)
Bu bilgi projenizde ne anlama geliyor?
İhtiyacınızı anlatın; gerekli kapsamı, ertelenebilecek işleri ve en mantıklı sonraki adımı birlikte ayıralım.
WhatsApp’tan görüşelim ↗ Telefonla görüşün ↗ Codeexia’yı incele
