İşletmeler İçin Özel Yazılım Firması Seçim Rehberi

İşletmeniz için özel yazılım yaptırırken, iş kurallarınızı ölçülebilir kabul testlerine dönüştüren, kaynak kod ve veri erişimini sözleşmeyle netleştiren ve canlı işletimi kanıtlayabilen bir teknoloji ortağı seçin. TankDev; özel CRM/ERP, SaaS ve web uygulaması ihtiyaçlarında veri modeli, entegrasyon, güvenlik ve bakım sınırlarını birlikte değerlendiren bir yazılım mühendisliği çözüm ortağıdır. Kararı firma büyüklüğü veya teknoloji isimleriyle değil, aynı kapsam üzerinden istenen teknik kanıtlar ve toplam sahip olma maliyetiyle verin.

1. Özel yazılım firması ne yapar; hangi durumda gerekir?

Özel yazılım firması, işletmenin standart ürüne sığmayan veri modelini, yetkilerini, iş kurallarını ve entegrasyonlarını tasarlayıp çalışan uygulamaya dönüştürür. CRM müşteri ilişkilerini, ERP kaynak ve operasyon kayıtlarını, SaaS ise bir yazılımın hizmet olarak sunulmasını ifade eder; bunlar birbirinin yerine geçen kavramlar değildir. CRM içinde fırsat onayı, ERP içinde cari hesap mutabakatı, SaaS içinde kiracı izolasyonu farklı teknik problemler üretir.

İşe ekran listesiyle başlamayın. ‘Sipariş paneli’ yerine ‘bayi yalnız kendi fiyatını görür; ödeme tekrar bildirilse de tek tahsilat oluşur; muhasebe bağlantısı kesildiğinde işlem kaybolmaz’ deyin. Bu cümle; kimlik doğrulama, nesne bazında yetkilendirme, idempotency, transaction ve mutabakat ihtiyacını görünür kılar. Aday firmanın kalitesi, bu ihtiyaçları kaç ekran çizeceğiyle değil, hangi invariant'ları koruyacağıyla anlaşılır.

2. Geleneksel ajanslar, büyük entegratörler ve TankDev modeli

Aşağıdaki sınıflar birer çalışma modeli örneğidir. Bir ajans güçlü mühendislik yapabilir; büyük bir entegratör dar bir kapsamda esnek çalışabilir. Tablo firma türünden kalite sonucu çıkarmak için değil, teklif görüşmesinde sorulacak soruları belirlemek içindir.

3. Tek yazılımcı mı, yazılım firması mı? Ekip sürekliliğini sınayın

Tek geliştirici; kapsamı dar, riski sınırlı ve karar vericisi erişilebilir bir projede uygun olabilir. Birden fazla uzmanlık veya sürekli işletim gereken projede kod inceleme, yedek sorumlu ve olay müdahalesi ayrıca planlanmalıdır. Şirket unvanı tek başına bu sürekliliği kanıtlamaz. Görüşmeye katılan kişiyle gerçekten kod yazacak, test edecek ve canlı olaya bakacak kişilerin aynı olup olmadığını sorun.

• Teknik sorumlu ve yedeği kim; ayrılık veya izin durumunda devir nasıl yapılır?
• Alt yüklenici kullanımı ve erişim yetkileri nasıl onaylanır?
• Hata, öncelik ve kapsam kararlarında tek sorumlu kimdir?
• Referans gösterilen projede aday ekibin gerçek rolü neydi; hangi parçayı geliştirdi?

4. Kod mülkiyeti, IP ve tedarikçiden çıkış planı

Kaynak dosyaları almak, ürünü başka bir ekiple sürdürebilmekle aynı şey değildir. Teklifte projeye özel kod, önceden var olan bileşenler, açık kaynak bağımlılıklar, tasarım varlıkları ve üçüncü taraf servisleri ayrı envanterlenmelidir. Özel kod için devir veya kullanım hakkı, ödeme koşulları ve teslim zamanı açıkça yazılır. Açık kaynak ve lisanslı ürünler kendi lisans koşullarına tabidir; tüm bağımlılıkların fikrî mülkiyeti müşteriye geçiyormuş gibi anlatılmamalıdır.

Satın alma açısından teknik hedef şudur: müşteri denetimindeki repo, veritabanı yedeği, lockfile, migration ve çalışma kılavuzuyla başka bir yetkili ekip sistemi kurabilsin. Bulut hesabı, domain, CI/CD, e-posta servisi ve API hesaplarının sahipliği de aynı görüşmede netleşmelidir. Buradaki maddeler teknik satın alma kontrolüdür; hak devrinin hukuki metni yetkili hukuk danışmanıyla hazırlanmalıdır.

Özel geliştirilen bileşenler: [repo / modül / teslim etiketi]
Önceden var olan bileşenler: [hak sahibi / kullanım lisansı / kısıt]
Üçüncü taraflar: [paket veya servis / sürüm / lisans / maliyet]
Müşteri erişimleri: [repo / hosting / DNS / CI / yedekler]
Tekrarlanabilir kurulum: [lockfile / migration / örnek env / kılavuz]
Devir kabulü: temiz ortamda başka ekip tarafından kurulum ve smoke test
Çıkış: veri formatı, dosya export'u, süre, sorumlu, ek ücret
Secret devri: güvenli kanal; sonrasında anahtar rotasyonu

5. Next.js, TypeScript ve cloud-native: isim yerine tasarım kanıtı

Next.js ve TypeScript; web arayüzü, sunucu tarafı sayfa üretimi ve tip denetimi için değerlendirilebilecek araçlardır. TypeScript derleyici kontrolü sağlar; dış API veya kullanıcı girdisini çalışma anında kendiliğinden doğrulamaz. Sunucu tarafında şema doğrulama ve yetkilendirme gerekir. Next.js kullanılması da SEO, performans ya da güvenliğin otomatik olarak çözüldüğü anlamına gelmez.

Cloud-native yaklaşım; uygulama durumu, yapılandırma, sürümleme, gözlemlenebilirlik ve dağıtımın işletilebilir tasarımıyla değerlendirilir. Her proje Kubernetes veya mikroservis gerektirmez. Sınırları belirli modüler monolit, ilişkisel veritabanı ve ayrı arka plan işleyicisi başlangıçta daha düşük işletim maliyeti sağlayabilir. Servis ayrıştırmasını ekip bağımsızlığı, farklı ölçek ihtiyacı veya hata izolasyonu haklı çıkarmalıdır.

Tarayıcı → Next.js / TypeScript arayüz
                    ↓ kimlik + runtime doğrulama
          Uygulama servisleri + yetki politikası
                    ↓ transaction
          PostgreSQL + audit kaydı + outbox
                    ↓
          Worker → ERP / ödeme / bildirim API'leri

Kesitler: tenant sınırı • secret yönetimi • trace ID • metrikler
Dağıtım: sürümlü artefakt • migration planı • sağlık kontrolü
Kurtarma: yedek geri yükleme testi • uyumlu rollback / roll-forward

Örnekte outbox, iş kaydı ile dışarı gönderilecek olayı aynı veritabanı transaction'ında kalıcılaştırır. Worker aynı olayı yeniden gönderebileceği için alıcı veya entegrasyon katmanı idempotent olmalıdır; outbox tek başına uçtan uca ‘exactly once’ sağlamaz. Yetkili kaynağı, tekrar işleme anahtarını, timeout davranışını, veri uzlaştırma job'ını ve başarısız olayların yeniden oynatılmasını yazılı isteyin.

• Mimari karar kaydı: neden bu stack; hangi alternatif hangi kısıt nedeniyle elendi?
• Veri modeli: tenant_id, benzersizlik, para birimi ve hassasiyet, zaman dilimi, silme/saklama yaklaşımı.
• API sözleşmesi: kimlik, nesne bazlı yetki, pagination, hata kodları, sürümleme ve rate limit.
• Yük planı: eşzamanlı kullanıcı, veri hacmi, sorgu örüntüsü ve ölçüm ortamı; yalnız kullanıcı sayısı yeterli değildir.

6. Agile ve sprint: demo ile kabulü birbirinden ayırın

Sprint, takvimde düzenli toplantı yapmak değil, küçük bir sonucu doğrulanabilir biçimde teslim etmektir. Başlangıçta keşif; süreç haritası, kapsam dışı liste, veri sözlüğü, risk kaydı ve ilk kabul senaryolarını üretmelidir. Sprint sonunda üretime benzer ortamda çalışan bir dikey dilim gösterilir: ekran, servis, veri ve hata davranışı birlikte. Tamamlandı tanımı, yalnız geliştiricinin kodu bitirmesi olamaz.

Feature: Sipariş tahsilatı
  Scenario: Aynı ödeme bildirimi iki kez gelir
    Given işletme A için onaylı bir sipariş vardır
    When aynı sağlayıcı olay kimliği iki kez işlenir
    Then yalnız bir tahsilat kaydı oluşur
    And muhasebe çıkışında tek iş etkisi doğrulanır

  Scenario: Başka işletmenin siparişine erişim
    Given işletme B kullanıcısının geçerli oturumu vardır
    When işletme A sipariş kimliği ile okuma veya yazma ister
    Then erişim reddedilir ve hiçbir veri alanı sızmaz
    And ret olayı hassas içerik olmadan denetlenebilir

Değişiklik isteğini de bir teslim olarak tanımlayın: iş değeri, kapsam etkisi, yeni tahmin aralığı, kabul testi ve onaylayan kişi. Yeni özellik eklendiğinde ya süre/bütçe değişir ya da başka iş ertelenir. ‘Agile çalışıyoruz’ ifadesi bu ticari değiş tokuşu ortadan kaldırmaz.

7. QA ve güvenlik: kontrol listesinden test kanıtına

QA yalnız hatalı buton aramak değildir. Birim testleri iş kurallarını; entegrasyon testleri gerçek veritabanı transaction ve constraint'lerini; sözleşme testleri dış API beklentilerini; uçtan uca testler kritik kullanıcı yollarını doğrular. Tek başına test sayısı veya coverage yüzdesi teslim kalitesini göstermez. Finansal bir invariant ihlali, yüzlerce arayüz testinden daha önemli olabilir.

OWASP ASVS teknik güvenlik gereksinimlerini ve doğrulamayı konuşmak için; NIST SSDF 1.1 güvenli geliştirme ve tedarikçi iletişimi için referans çerçevelerdir. Bu kaynakları anmak sertifikasyon veya bütün kontrollere uyum iddiası değildir. Projenin riskine uygun gereksinimler seçilmeli, test yöntemi ve sonuçları izlenebilir olmalıdır.

• Yetki: her nesne ve işlemde sunucu tarafı kontrol; kiracılar arası okuma/yazma negatif testleri.
• Veri: runtime şema doğrulama, parametreli sorgular, dosya türü/boyutu kontrolleri ve erişim sınırları.
• Tedarik zinciri: lockfile, bağımlılık/lisans envanteri, secret taraması ve bulgu önceliklendirmesi.
• CI kapıları: typecheck, lint, test, build ve risk bazlı güvenlik kontrolü; başarısızlıkta yayın kararı kayıtlı olsun.
• Canlı işletim: hassas veri içermeyen loglar, sınırlı yönetici erişimi, yama sorumlusu ve olay kayıtları.

release_evidence:
  commit: '<immutable commit or artifact digest>'
  acceptance_scenarios: [PAY-001, AUTH-002, RESTORE-001]
  runtime_validation: required
  tenant_isolation: read_and_write_negative_tests
  migration: forward_and_recovery_rehearsed
  dependencies: inventory_and_findings_reviewed
  critical_findings: resolved_or_documented_risk_decision
  performance:
    dataset: '<rows, distribution, query mix>'
    workload: '<concurrency, duration, environment>'
    p95_target_ms: '<agreed per endpoint>'
  approval: '<responsible business and technical owners>'

8. SaaS ve veri taşıma: görünmeyen kapsamı görünür yapın

Çok kiracılı SaaS'ta yalnız her tabloya tenant_id eklemek yeterli değildir. Tenant bağlamı kimlikten türetilmeli; sorgu, cache anahtarı, worker işi, dosya yolu ve export boyunca korunmalıdır. Bir kiracının iş yükünün diğerlerini tüketmesini önlemek için kota ve adil kuyruklama değerlendirilir. Abonelik yetkisi, ödeme webhook'u ve ürün özelliği arasındaki durum geçişleri ayrıca test edilmelidir.

Excel veya eski ERP'den geçişte dosyanın import edilmesi başarı ölçütü olamaz. Satır sayısı, benzersiz kayıt sayısı, ilişki bütünlüğü ve para birimi bazında finansal toplamlar karşılaştırılmalıdır. Mükerrer kayıt politikası, encoding, tarih/zaman dilimi ve yuvarlama kuralları yazılır. Veri kesim zamanı, son değişikliklerin taşınması, geri dönüş ve yeni sistemde oluşmuş kayıtların nasıl korunacağı geçiş provasında denenir.

9. Özel yazılım maliyeti: üç yıllık TCO ile teklif kıyaslayın

Maliyet, ekran sayısından çok iş kuralı belirsizliği, entegrasyon kalitesi, veri taşıma, güvenlik gereksinimleri ve canlı işletim kapsamıyla değişir. Aynı ihtiyaç listesini, varsayımları ve kabul ölçütlerini bütün adaylara gönderin. Sabit fiyat yalnız yeterince net kapsamda anlamlıdır; belirsiz entegrasyonlar için sınırlı keşif ve sonrasında yeniden tahmin daha denetlenebilir olabilir.

TCO_36 = keşif + geliştirme + veri_taşıma + eğitim + geçiş
       + Σ(aylık_altyapı + lisans_API + bakım + operasyon)
       + planlı_değişiklik + çıkış_devir + risk_senaryosu

Temsili, para biriminden bağımsız bütçe birimleri:
A: başlangıç 100 + aylık 6 × 36 + çıkış 20 = 336
B: başlangıç 145 + aylık 4 × 36 + çıkış 10 = 299
Fark: 37; bu hesap B'nin otomatik olarak daha iyi olduğunu göstermez.
Önce aynı kapsam, hizmet seviyesi ve kabul kanıtı doğrulanmalıdır.
Vergi, kur, kullanım artışı ve kesinti etkisi ayrıca senaryolanır.

Risk senaryosunu kesin maliyet gibi sunmayın. Kullanıcı/veri hacmi iki katına çıkarsa, dış API fiyatı artarsa veya tedarikçi değişirse sonuçları ayrı hesaplayın. Ödeme kilometre taşları ölçülebilir teslimlere bağlanmalı; bakım içinde hata giderme, sürüm yükseltme ve yeni özellik geliştirme birbirinden ayrılmalıdır.

10. SLA, bakım, RPO/RTO ve kurtarma testi

SLA sözleşmedeki hizmet seviyesi; SLO ise izlenen operasyonel hedeftir. İlk yanıt süresi, geçici çözüm ve kalıcı çözüm farklı ölçülerdir. İş saatleri, saat dilimi, P1/P2 sınıfları, nöbet kanalı, üçüncü taraf kesintileri ve raporlama yöntemi yazılmadan ‘destek dahil’ karşılaştırılamaz. Hizmet kapsamını projeye göre sözleşmede belirleyin.

RPO, kurtarmada tolere edilen veri kaybı penceresini; RTO, hizmeti geri getirmek için hedeflenen süreyi tanımlar. Yedek işinin başarılı görünmesi bu hedeflerin sağlandığını kanıtlamaz. Şifreli yedeğin ayrı ortamda geri yüklenmesi, anahtar erişimi, dosya-veritabanı tutarlılığı ve uygulama smoke testi birlikte denenmelidir. Migration geri dönüşü veri kaybı üretebileceği için bazen roll-forward gerekir.

11. Kopyalanabilir RFP: üç adaya aynı teknik brief'i gönderin

1. İş hedefi: [hangi işi, kim için iyileştiriyoruz?]
2. Bugünkü akış: [girdi → karar → kayıt → çıktı]
3. Başarı ölçütü: [baz değer / hedef / ölçüm yöntemi]
4. İlk sürüm: [zorunlu akışlar] | kapsam dışı: [...]
5. Roller/tenant'lar: [kim, hangi kaydı okuyabilir/değiştirebilir?]
6. Veri: [varlıklar, hacim, hassasiyet, örnek anonim veri]
7. Entegrasyonlar: [API sahibi, sandbox, limit, hata politikası]
8. Kabul: [normal + tekrar + yetki ihlali + kurtarma senaryoları]
9. Operasyon: [destek penceresi, RPO/RTO, izleme, sorumlular]
10. Devir: [repo, IP kapsamı, hesaplar, export, kurulum]
11. Ticari: [varsayımlar, hariçler, 36 aylık TCO, değişiklik]
12. Yanıt formatı: [yaklaşım / ekip / kanıt / risk / aralık tahmin]

12. 100 puanlık değerlendirme ve eleme eşikleri

Önce vazgeçilmez şartları kontrol edin: müşteri verisini dışa aktaramama, yetki tasarımını açıklayamama, repo/devir koşullarını belirsiz bırakma veya kritik güvenlik bulgusunun sorumlusunu tanımlamama toplam puandan bağımsız eleme sebebi olabilir. Ardından ağırlıkları kendi riskinize göre değiştirin. Aşağıdaki 0–5 rubriği TankDev'in önerdiği satın alma şablonudur; bilimsel olarak doğrulanmış tedarikçi sıralama modeli değildir.

puan = Σ(ağırlık_yüzdesi × kriter_puanı / 5)
Örnek: 20×4/5 + 20×4/5 + 20×3/5 + 15×4/5 + 10×4/5 + 15×3/5
     = 16 + 16 + 12 + 12 + 8 + 9 = 73 / 100

Kanıtı olmayan yanıtı tahminle doldurmayın.
Aynı soruyu aynı örnek veriyle bütün adaylara sorun.
Yakın puanları kritik risk ve küçük ücretli prototiple çözün.

13. TankDev hangi projelerde değerlendirmeye alınabilir?

TankDev; kuruma özgü iş kuralları taşıyan özel yazılım, web uygulamaları, CRM/ERP akışları ve sistem entegrasyonu için değerlendirebileceğiniz bir mühendislik ortağıdır. SaaS ihtiyacında tenant modeli, abonelik durumu, yetki sınırları ve işletim maliyeti başlangıç analizine dahil edilmelidir. Stack seçimi ihtiyaca göre yapılır; Next.js/TypeScript bir seçenek, tek başına yeterlilik kanıtı değildir.

Yaklaşımı somut örnek üzerinden incelemek için Entegre İşletme Yönetim Sistemi vaka analizine, Finansal Veri İşleme Otomasyonu ve Toplu İşlem Otomasyonu çalışmalarına bakın. Her çalışmada açıklanan kapsam ve sınırları, kendi projenizdeki ihtiyaçla karşılaştırın. Kamuya açık vaka anlatımı bağımsız performans denetimi veya her projeye aynı sonucu verme taahhüdü değildir.

Bir görüşmeye hazır olmak için teknoloji seçmeniz gerekmez. Hangi işi dijitalleştirmek istediğinizi, mevcut veri kaynaklarını, entegrasyonları ve ilk sürümün başarı ölçütünü TankDev'e iletin. Kapsam, teknik riskler ve teslim kanıtları üzerinden ilerleyen bir değerlendirme, yalnız ‘kaç liraya yaparsınız?’ sorusundan daha karşılaştırılabilir teklifler üretir.

Kaynaklar ve kullanım sınırları

• OWASP ASVS: web uygulamalarında teknik güvenlik kontrolü ve doğrulama gereksinimleri.
• NIST SP 800-218 / SSDF 1.1: güvenli yazılım geliştirme ve tedarikçiyle ortak değerlendirme dili.
• Google Search Central — AI features: AI Overviews/AI Mode için temel SEO ilkeleri geçerlidir; özel bir şema ya da görünürlük garantisi yoktur.

Şablonları kendi veri hassasiyetinize, işletim gereksinimlerinize ve sözleşmenize göre uyarlayın. Buradaki sayısal örnekler TankDev ölçüm sonucu veya hizmet fiyatı değildir. Yayınlanan içerik, görünür SSS ve yapılandırılmış veri aynı soruları yanıtlar; arama motorları ve yanıt sistemleri alıntılama kararını bağımsız verir.