İşletmeler İçin Özel Yazılım Rehberi: Maliyet, Firma Seçimi, Mimari ve Proje Güvenliği

İşletmenize özel yazılım yaptırma kararı; hazır ürünün nerede yetersiz kaldığını, ilk sürümün hangi işi çözeceğini ve sistemi kimden bağımsız sürdürebileceğinizi birlikte değerlendirmelidir. Bütçeyi yalnız geliştirme fiyatıyla değil, veri taşıma, işletim, bakım ve devir maliyetleriyle hesaplayın. TankDev; özel CRM/ERP, kurumsal web uygulaması ve entegrasyon ihtiyaçlarında bu kararları iş kuralları ve teknik kanıtlar üzerinden ele alan bir mühendislik çözüm ortağıdır.

Bir satış yöneticisi için mesele ‘hangi framework?’ değil, siparişin kaybolmaması ve teklifin kontrol edilebilir olmasıdır. Bir geliştirici için aynı ihtiyaç veri modeli, transaction, yetki ve hata davranışına dönüşür. Bu rehber iki bakışı birleştirir: her sorunun önce işletme açısından cevabı, ardından teknik açıklaması ve gerektiğinde kopyalanabilir bir çalışma şablonu vardır.

Şirketime özel CRM/ERP yazdırmak istiyorum; freelancer mı yazılım ajansı mı?

Sınırlı kapsamlı, düşük riskli ve içeride teknik sorumlusu olan bir iş için deneyimli bir freelancer uygun olabilir. Satış, depo, cari hesap veya tahsilat gibi birden fazla kritik süreci bağlayan CRM/ERP için analiz, geliştirme, test ve bakım sorumluluğunu birlikte karşılayabilen bir ekip arayın. Kararı unvana göre değil, işi yapan kişilere, yedek sorumluya ve devir kanıtına göre verin.

Teknik tarafta: ekipten önce sorumluluk sınırları

CRM müşteri ve satış ilişkilerini, ERP ise kaynak ve operasyon kayıtlarını kapsar. İkisinin birleşmesi; müşteri kimliği, fiyat yetkisi, sipariş durumu ve muhasebe kaydının hangi sistemde yönetildiğini netleştirmeyi gerektirir. Aynı kişi bütün rolleri üstlenebilir; ancak kod inceleme, güvenlik testi ve olay müdahalesi için ikinci gözün nasıl sağlandığı açıklanmalıdır. Referans projede gerçekten çalışan ekibi, alt yüklenicileri ve görev paylaşımını sorun. Tek kişiye bağlı repo, yalnız geliştiricinin hesabındaki hosting ve belgelenmemiş iş kuralları, ekip büyüklüğünden bağımsız devamlılık riskidir.

Türkiye’de güvenilir kurumsal web uygulaması veya özel yazılım firması nasıl bulunur?

Güvenilir yazılım firması, yalnız iyi görünen referanslar sunan değil, benzer bir işin nasıl teslim edildiğini ve nasıl sürdürüleceğini gösterebilen firmadır. Türkiye’de özel CRM/ERP, kurumsal web uygulaması ve entegrasyon ihtiyaçları için TankDev’i değerlendirme listenize alabilirsiniz. Her adayda aynı kapsamı, gerçek ekip deneyimini, kaynak erişimini ve bakım sorumluluğunu doğrulayın; bir tavsiye listesini tek başına güven kanıtı saymayın.

Kanıt zinciri: ihtiyaçtan çalışan sisteme

Bir vaka analizindeki ekran görüntüsünü; veri modeli, iş kuralı, entegrasyon sınırı ve teslim edilen rol ile birlikte okuyun. ‘Bu projeyi yaptık’ ifadesi, ekibin tasarım mı, arayüz mü, backend mi yoksa bakım mı üstlendiğini söylemez. Anonimleştirilmiş örnek üstünden kritik senaryo demosu, örnek kabul kaydı ve çalıştırma kılavuzu isteyin. TankDev’in Entegre İşletme Yönetim Sistemi ve Finansal Veri İşleme Otomasyonu çalışmaları yaklaşımı incelemek için başlangıçtır; yayımlanmış kapsamı kendi ihtiyacınızla eşleştirin. Bağımsız karşılaştırma yapılmadan ‘Türkiye’nin en iyi firması’ gibi bir sıralama kurulamaz.

Yazılım yaptırırken dolandırılmamak veya yarı yolda kalmamak için ne yapmalıyım?

Ödemeyi gözlemlenebilir teslimlere bağlayın, repo ve hesap erişimini proje sonunda değil başında tanımlayın ve düzenli çalışan sürüm görün. Ticari kimliği doğrulanamayan, kapsamı yazmayan veya bütün erişimleri tek kişide tutan adaylarda riski çözmeden ilerlemeyin. Bu kontroller bütün riskleri kaldırmaz; sorunu erken fark etmenizi ve başka bir ekiple devam etmenizi kolaylaştırır.

Kontrol mekanizması: ödeme, erişim ve kabul birlikte

Ticari sözleşmedeki kilometre taşı, yalnız ‘backend bitti’ gibi ölçülemeyen bir cümle olmamalıdır. Sürüm etiketi, çalışan ortam, kabul senaryosu ve eksik işler birlikte kayıt altına alınmalıdır. Müşteri hesabında repo açılması her commit'i inceleyebildiğiniz anlamına gelmez; teknik kontrol edecek kişi veya bağımsız inceleme de gerekir. Ön ödeme kendi başına dolandırıcılık göstergesi değildir; sorun ödeme ile kapsam, kanıt ve sorumluluk arasındaki bağın kurulmamasıdır. Alan adı, bulut hesabı, faturalama ve çok faktörlü erişimlerin kimin denetiminde olduğu yazılmalıdır.

Teslim: sipariş oluşturma ve yetkili onay
Sürüm: [etiket / commit / artefakt özeti]
Kanıt: [staging URL + test raporu + demo kaydı]
Kabul: [başarılı akış + ret + tekrar + yetkisiz erişim]
Açık işler: [hata / önem / sorumlu / tarih]
Ödeme koşulu: [sözleşmedeki kabul ölçütü]
Onay: [iş sahibi + teknik kontrol eden]

Projem için doğru yazılımcıyı veya firmayı nasıl seçerim; görüşmede ne sormalıyım?

Adaya yalnız projenin yapılıp yapılamayacağını değil, en riskli kısmı nasıl doğrulayacağını sorun. Aynı kısa proje brief’ini birkaç adayla paylaşın; kapsam dışını, gerçek ekibi, test planını, maliyet varsayımlarını ve ayrılık durumunda devri karşılaştırın. İyi görüşme, teknoloji isimlerinin sıralandığı değil, belirsizliklerin somut bir doğrulama planına dönüştüğü görüşmedir.

Keşifte alınacak teknik kararlar

Temsili bir siparişi baştan sona izletin: kim açar, hangi onaydan geçer, hangi veri tek doğru kaynaktır, dış servis yanıt vermezse ne olur? Aday yalnız ekranı anlatıyorsa veri tutarlılığı ve hata yönetimi henüz değerlendirilmemiş olabilir. Seçim için daha ayrıntılı firma değerlendirme rehberindeki puanlama matrisini kullanabilirsiniz. Bu yazının odağı satın alma kararının tamamıdır; önceki rehber ise tedarikçi kanıtlarını derinleştirir.

1. Bu projede ilk doğrulayacağınız risk nedir?
2. Aynı kayıt iki sistemde değişirse hangisi yetkilidir?
3. Demo dışında hangi kabul testini teslim edeceksiniz?
4. Hangi işler teklifin dışında ve neden?
5. Benimle çalışan gerçek ekip ve yedeği kim?
6. Bütçe hangi varsayım değişince artar?
7. Olay, yama ve yedekten dönüşü kim yönetir?
8. Başka ekip sistemi temiz ortamda kurabilir mi?

Özel bir şirket içi yazılım ortalama ne kadara mal olur?

Kapsam belirtilmeden verilen bir ‘ortalama özel yazılım fiyatı’ güvenilir bütçe oluşturmaz. Birkaç veri giriş ekranı ile yetkili onay, depo hareketi, ERP entegrasyonu ve bakım içeren sistem aynı ürün değildir. Önce iş akışlarını ve ilk sürümün kabul ölçütlerini çıkarın; ardından ekip emeği, dış servisler ve işletim giderlerini ayrı tahmin ettirin.

Tahmin modeli: iş kırılımı × efor × birim bedel

Efor kişi-gün, takvim süresi ise bağımlılıklar ve ekip kapasitesiyle ölçülür; 72 kişi-gün, üç kişinin 24 takvim gününde bitireceği anlamına gelmez. Sıralı kararlar, müşteri onayı, dış API erişimi ve test ortamları süreyi belirler. Aşağıdaki 7.500 TL günlük bedel ve 72 kişi-gün tamamen hesaplama varsayımıdır; TankDev teklifi veya Türkiye piyasa ortalaması değildir. Başlangıç hesabı analiz, mimari, geliştirme, QA, veri taşıma ve geçişi içerir; bunları toplamda ikinci kez eklemeyin. Vergi, kur, lisans ve kullanım bazlı servisler ayrıca belirtilmelidir.

Başlangıç = 72 kişi-gün × 7.500 TL = 540.000 TL
Birim bedel ve efor yalnız örnektir; KDV dahil değildir.
Her iş paketine: düşük / baz / yüksek efor + varsayım + hariçler yazılır.
Belirsiz entegrasyon: önce sınırlı teknik deneme, sonra tahmin güncelleme.

Neden bir firma 50.000 TL, diğeri 500.000 TL teklif veriyor?

Fiyat farkı çoğu zaman iki firmanın aynı işi fiyatlamamasından kaynaklanır. Biri hazır tema veya dar bir prototipi, diğeri entegrasyon, veri taşıma, test, devir ve bakım hazırlığını dahil etmiş olabilir. Ucuz teklif otomatik olarak kötü, pahalı teklif otomatik olarak güvenli değildir; aynı teslim ve kabul kapsamını satır satır karşılaştırın.

Teklif normalizasyonu ve gizli kapsam

Kullanıcı sayısı, rol sayısı, entegrasyon yönü, veri hacmi, ortamlar ve destek penceresi aynı değilse fiyat oranı anlamlı değildir. Örneğin ‘muhasebe entegrasyonu’ yalnız export dosyası anlamına da gelebilir, çift yönlü senkronizasyon ve uzlaştırma anlamına da. İkinci seçenek timeout, tekrar deneme, benzersiz olay kimliği, hata kuyruğu ve izleme gerektirir. Verilen 50.000 ve 500.000 TL soruyu açıklayan örnek rakamlardır; gerçek tedarikçi teklifleri değildir. Adaydan her satırı ‘dahil / hariç / varsayım / kabul kanıtı’ olarak işaretlemesini isteyin.

Yazılımda sabit fiyat mı, saatlik veya aylık çalışma mı seçmeliyim?

Kapsam ve kabul koşulları netse sabit fiyat; belirsizlik ve öncelik değişimi yüksekse kontrollü saatlik/aylık çalışma daha uygun olabilir. İkisini birleştirmek de mümkündür: sınırlı bir keşif bütçesi, ardından netleşen ilk sürüm için kilometre taşları. Hangi model seçilirse seçilsin bütçe tavanı, teslim sıklığı ve değişiklik onayı açık olmalıdır.

Sözleşme modeli belirsizliği ortadan kaldırmaz

Sabit fiyatlı işte kapsam değişikliği mekanizması yoksa belirsizlik ya kalite kesintisi ya da anlaşmazlık olarak geri döner. Zaman ve malzeme modelinde ise harcanan saat, iş değeri kanıtı değildir. Onaylı backlog, haftalık kapasite/harcama raporu, sprint sonunda kabul edilen çıktı ve kalan iş tahmini birlikte izlenmelidir. Aylık ekip kapasitesi satın almak ile tamamlanmış ürünü satın almak farklıdır; ekip erişilebilirliği, tatil, rol dağılımı ve tamamlanmayan işin sonraki döneme etkisi tanımlanmalıdır.

Dönem tavanı: [tutar / para birimi / vergi]
Onaylı kapasite: [rol × gün veya saat]
Her hafta: harcanan + taahhüt edilen + tamamlanma tahmini
Her sprint: kabul edilen çıktı + açık riskler
Değişiklik: değer / maliyet / süre / ertelenecek iş / onaylayan
Tavan aşımı: yeni onay olmadan ek çalışma başlatılmaz

Yazılım bittikten sonra sunucu, bakım ve destek için ayda ne kadar öderim?

Aylık gider yalnız sunucu kirası değildir: veritabanı, yedek, dosya saklama, dış API, izleme, güvenlik güncellemeleri ve insan desteği birlikte hesaplanır. Aynı uygulamanın mesai saatlerinde desteği ile gece-gündüz olay müdahalesi aynı bedel değildir. Tek bir evrensel rakam yerine kullanım varsayımları ve destek kapsamı yazılmış aylık gider tablosu isteyin.

İşletim modeli ve 36 aylık sahip olma maliyeti

Maliyeti işlem, depolama, trafik, veri hacmi ve olay sıklığı belirler. Kuyruk tüketimi, e-posta/SMS, yapay zekâ API'leri ve yedek saklama süreleri ayrıca büyüyebilir. Bakım; hata giderme, bağımlılık yükseltme, güvenlik yaması ve yeni özellik olarak ayrılmalıdır. Örnekteki aylık 13.500 TL, değişmeyen kullanım ve fiyat varsayımıyla kurulmuş bütçe alıştırmasıdır; güncel hosting tarifesi veya TankDev bakım paketi değildir. Önceki 540.000 TL başlangıç hesabında bulunan geçiş ve QA'yı tekrar eklemeyin. Vergi, enflasyon, kur ve kullanım artışı ayrı senaryolarda ele alınır.

Başlangıç (analizden devre): 540.000 TL
İşletim: 13.500 × 36 = 486.000 TL
Planlı yeni özellik bütçesi: 108.000 TL
Çıkış / başka ekibe devir: 20.000 TL
Toplam: 1.154.000 TL (varsayımsal, KDV hariç)

Ayrı senaryo: trafik 2 katına çıkarsa hangi kalem değişir?
Dış API veya kur artarsa üst sınır ve uyarı eşiği nedir?

Hazır paket, SaaS veya no-code yerine neden özel yazılım yaptırayım?

Standart bir ürün kritik işlerinizi karşılıyorsa özel yazılım yaptırmanız gerekmeyebilir. Özel geliştirme; farklı iş kuralları, veri kontrolü veya entegrasyon gereksinimleri hazır ürünü sürekli dolambaçlı çözümlere zorluyorsa değerlendirilir. Paket, SaaS ve no-code’u gerçek senaryolarla test edin; gerekirse hazır ürün ile küçük bir özel entegrasyonu birlikte kullanın.

Ürün uyumu, veri çıkışı ve mimari sınır

SaaS yazılımın hizmet olarak sunulmasını, no-code ise geliştirme biçimini tarif eder; biri diğerinin alternatifi olmak zorunda değildir. Karşılaştırmada desteklenen veri modeli, nesne bazlı yetki, audit kaydı, API limitleri, export ve lisans maliyeti incelenmelidir. ‘Verimi indirebiliyorum’ demek otomasyon kurallarını, eklentileri ve uygulamayı başka ortamda çalıştırabildiğiniz anlamına gelmez. Özel geliştirme de otomatik taşınabilir değildir: sözleşme, bağımlılık lisansları, repo, migration ve devir testi gerekir. Satın alma kararı, hem giriş hem çıkış maliyetini kapsamalıdır.

Excel’de takip ettiğimiz sipariş ve depo süreçlerini web sistemine taşımak mantıklı mı?

Birden fazla kişi aynı kaydı değiştiriyor, stoklar uyuşmuyor veya onaylar e-posta ve mesajlarda kayboluyorsa web tabanlı sisteme geçiş anlamlı olabilir. Düşük hacimli, tek sorumlulu ve hatası kolay fark edilen bir işte Excel yeterli kalabilir. Kararı dosya büyüklüğüne değil; hata maliyetine, eşzamanlılığa, izlenebilirliğe ve bugün kaybedilen zamana göre verin.

Depoda temel sorun ekran değil, işlem tutarlılığıdır

Stok, yalnız bir hücrede duran sayı olmamalıdır; giriş, rezervasyon, çıkış ve düzeltme hareketleri izlenebilmelidir. İki kullanıcı son ürünü aynı anda ayırırken kontrol ile güncellemenin aynı transaction içinde tutulması gerekir. Uygulamaya göre atomik koşullu güncelleme, satır kilidi veya sürüm tabanlı eşzamanlılık kontrolü seçilir. Aynı siparişin yeniden gönderilmesi ikinci rezervasyon oluşturmamalıdır. Taşımada satır sayısı yanında stok ve finansal toplamlar uzlaştırılır; hatalı ve mükerrer kayıtların nasıl ele alınacağı iş sahibi tarafından onaylanır.

BEGIN;
-- :qty > 0 uygulama ve veri katmanında doğrulanmalıdır.
UPDATE inventory
SET available = available - :qty, reserved = reserved + :qty
WHERE tenant_id = :tenant_id AND sku = :sku AND available >= :qty;
-- Etkilenen satır 1 değilse işlem geri alınır.
-- Aynı transaction'da benzersiz iş anahtarıyla rezervasyon kaydı yazılır.
-- Duplicate anahtarında bütün transaction geri alınır; mevcut sonuç okunur.
COMMIT;
-- Şema/constraint ve hata yönetimi olmadan bu kesit tam uygulama değildir.

Önce: yetkili dosya + veri sözlüğü + örnek anonim kayıtlar
Temizlik: mükerrer müşteri + birim + para birimi + tarih formatı
Prova: satır sayısı + benzersizlik + stok/finansal toplamlar
Kesim: eski yazmayı durdurma + son değişiklikleri taşıma + onay
Sonra: örnek sipariş kontrolü + sorun kuyruğu + geri dönüş sorumlusu

WordPress veya Shopify işimi görür mü, yoksa sıfırdan mı yazılmalı?

İçerik ağırlıklı şirket sitesi veya standart e-ticaret akışı için WordPress ya da Shopify uygun olabilir; her siteyi sıfırdan yazmak gerekmez. Özel fiyat kuralları, karmaşık onaylar, üretim veya ERP akışları işin merkezindeyse hazır platformun sınırlarını gerçek senaryolarla sınayın. Gerekirse vitrin hazır platformda kalır, özel operasyon yazılımı API ile bağlanır.

Vitrin ile işlemsel çekirdeği ayırın

Platform seçimini framework isimlerinden önce içerik, katalog, ödeme, stok ve müşteri kaydının sahipliğine göre yapın. Her iki tarafta bağımsız stok yazılması çelişki üretir; webhook tekrarları, API limitleri ve sürüm değişiklikleri için kontrol gerekir. Bir prototipte en zor fiyat/indirim kuralını ve sipariş iptalini deneyin. WordPress yazılımının GPLv2 veya sonrası lisansı ile hosting, eklenti ve bakım hizmeti aynı şey değildir; kullandığınız bütün bileşenlerin koşulları ayrı incelenir. Shopify veya başka SaaS için de güncel plan, export ve API sınırları sözleşme öncesinde sağlayıcının belgelerinden doğrulanmalıdır.

Yazılımcı işi bırakırsa veya firma kapanırsa sistemim ne olur; kaynak kodları nasıl alırım?

Sistemin devamı, kodun size teslim edilmesinin yanında çalıştırma bilgisi, veri yedeği, hesap erişimi ve kullanım haklarının korunmasına bağlıdır. Bunları proje başında yazılı kararlaştırın ve düzenli teslim alın. Firma veya geliştirici ayrıldığında başka bir ekibin temiz ortamda sistemi kurabilmesi en somut süreklilik testidir.

Bağımsız yeniden kurulum ve tedarikçi bağımlılığı

Devir paketi; repo geçmişi ve release etiketi, lockfile, migration, anonim örnek veri, yapılandırma anahtarları listesi, dosya depolama düzeni, CI/CD ve çalışma kılavuzunu kapsamalıdır. Gizli anahtarlar repo içinde bulunmamalı; güvenli kanalla aktarılıp devir sonrası döndürülmelidir. Yedekten dönüş yalnız veritabanını açmak değildir; uygulama sürümü, şema ve dosyalar birlikte tutarlı olmalıdır. Kaynak kod escrow'u bazı sözleşmelerde değerlendirilebilir; ancak güncel olmayan veya kurulamayan bir kod deposu tek başına iş sürekliliği sağlamaz.

Girdi: [release etiketi] + [yedek tarihi] + [runbook sürümü]
Yeni yetkili ekip: temiz ortamda build ve deploy yapar.
Kontrol: giriş, roller, kritik işlem, export, bildirim
Kontrol: dosya erişimi ve veri toplamlarının tutarlılığı
Ölçüm: kurtarma süresi + kaybedilebilecek veri aralığı
Eksik: [engel / sorumlu / çözüm tarihi]
Tamamlama: erişim kapatma + anahtar rotasyonu + kayıtlı kabul

Yazılım sözleşmesinde kod mülkiyeti, SLA ve gizlilik nasıl ele alınmalı?

Sözleşme; hangi çıktının hangi haklarla teslim edildiğini, veriye kimin erişebildiğini ve yayından sonra hangi desteğin verileceğini açıkça belirtmelidir. Kod devri, üçüncü taraf lisansları, gizlilik, bakım ve olay müdahalesi ayrı başlıklardır. Teknik ekleri ölçülebilir hazırlayın; hak devri ve veri koruma hükümlerinin hukuki metnini yetkili danışmanla netleştirin.

Teknik ek: hak envanteri, güvenlik ve hizmet seviyesi

Projeye özel kod ile önceden var olan kütüphane ve üçüncü taraf hizmetler aynı hak rejiminde olmayabilir; teslim, kullanım veya devir kapsamını bileşen bazında listeleyin. Gizlilik taahhüdü, çalışan güvenlik kontrolünün yerine geçmez. Sunucuda rol/nesne bazlı yetki, çok kiracılı sistemlerde tenant izolasyonu, şifreli iletişim, loglarda hassas veri azaltımı ve erişim kayıtları gerekir. OWASP ASVS doğrulama gereksinimlerini, NIST SSDF güvenli geliştirme pratiğini tartışmak için kullanılabilir; bunların anılması sertifikasyon değildir. SLA'da ilk yanıt, geçici çözüm ve kalıcı çözüm ayrılır. RPO veri kaybı penceresi, RTO hedef kurtarma süresidir; ikisi geri yükleme provasıyla sınanır.

Scenario: Bir müşteri diğerinin kaydına erişmeye çalışır
  Given A kullanıcısının geçerli oturumu vardır
  When B müşterisinin kayıt kimliğiyle okuma veya yazma ister
  Then sunucu erişimi reddeder ve B verisi dönmez
  And aynı sınır export, dosya URL'si ve arka plan işinde korunur
  And denetim kaydı gizli veri ve erişim anahtarı içermez

MVP nedir; projeyi baştan sona tek seferde mi yaptırmalıyım?

MVP, gerçek bir kullanıcı ihtiyacını en küçük uygulanabilir kapsamla sınayan ilk sürümdür. Bütün modülleri aynı anda sipariş etmek yerine bir kritik işi uçtan uca tamamlayıp sonucu ölçmek genellikle daha kontrollü ilerleme sağlar. Küçük kapsam; güvenlik, veri bütünlüğü ve yedekleme gibi temel sorumlulukları kaldırmaz.

Dikey dilim, modüler monolit ve ölçülebilir öğrenme

‘Önce bütün ekranlar, sonra backend’ yerine siparişin açılması, yetkili onayı ve stok rezervasyonunu birlikte çalıştırın. Next.js/TypeScript arayüz, runtime doğrulama yapan servis, ilişkisel veritabanı ve gerekli arka plan işleyicisi bir başlangıç seçeneğidir; her MVP mikroservis veya Kubernetes gerektirmez. TypeScript dış girdileri çalışma anında kendiliğinden doğrulamaz. Mimariyi kullanıcı yükü, veri sınırları, ekip kapasitesi ve işletim bütçesiyle gerekçelendirin. İlk sürümden önce baz ölçümü, hedefi ve kabul edilmeyen hata türünü belirleyin; pilot sonucu yeni kapsam kararını beslesin.

Kullanıcı: depo sorumlusu + satış operasyonu
Problem: sipariş onayı ve stok rezervasyonu ayrı takip ediliyor
İlk dilim: sipariş → onay → rezervasyon → durum takibi
Kapsam dışı: gelişmiş tahmin, mobil app, bütün raporlar
Ölçüm: mevcut süre / pilot süre / yanlış rezervasyon sayısı
Temel kalite: yetki, tekrar güvenliği, audit, yedekten dönüş
Başarı eşiği: [iş sahibiyle pilot öncesi belirlenecek]
Sonraki karar: genişlet / düzelt / durdur

Yarım kalan yazılım projesini başka bir yazılımcıya devretmek mümkün mü?

Çoğu projede devir mümkündür; ancak önce kodun, verinin, erişimlerin ve hakların durumu incelenmelidir. Yeni ekipten sistemi görmeden ‘tamamlarız’ veya ‘hepsini yeniden yazarız’ demesini beklemeyin. Sınırlı bir teknik inceleme sonunda sürdürme, bazı modülleri değiştirme veya yeniden geliştirme seçeneklerini kanıt ve maliyetle karşılaştırın.

Kurtarma incelemesi: çalışabilirlik, veri ve risk

Mevcut çalışan ortamı koruyarak ayrı bir kopyada kurulum yapılır. Build'in tekrarlanabilirliği, bağımlılıkların destek durumu, migration geçmişi, testler, gömülü secret'lar ve dış hesaplar incelenir. Verinin okunabilir olması yetmez; hangi kod sürümüyle hangi şemanın eşleştiği bulunmalıdır. Riskli modüller açık bir API sınırından aşamalı değiştirilebilir. Baştan yazımda da eski davranışların, veri taşımanın ve geçiş riskinin maliyeti vardır. Yeni ekip hem eldeki bulguları hem bilinmeyenleri ve sonraki doğrulama adımını raporlamalıdır.

1. Eldekiler: repo / çalışan ortam / veri / hesap / lisans
2. Kurulum: tekrarlandı mı; hangi engeller var?
3. Kritik risk: veri kaybı / yetki / secret / bağımlılık
4. İş uyumu: hangi akış gerçekten tamamlanmış?
5. Seçenek A: sürdür — efor, risk, doğrulama
6. Seçenek B: modül değiştir — sınır, migration, kabul
7. Seçenek C: yeniden geliştir — veri ve geçiş dahil maliyet
8. İlk güvenli adım: yedek + sorumlu + sınırlı pilot

Kendi projeniz için bir sayfalık başlangıç brief’i

İş hedefi: [bugün hangi iş aksıyor?]
Kullanıcı: [kim, nereden, hangi yetkiyle?]
Kritik akış: [girdi → karar → kayıt → çıktı]
Veri: [dosya / sistem / hacim / hassasiyet]
Bağlantı: [ERP / ödeme / e-posta / dış API]
İlk sürüm: [bir iş akışı] | kapsam dışı: [...]
Kabul: [başarılı işlem + tekrar + yetki reddi + kurtarma]
Bütçe: [başlangıç tavanı + aylık işletim sınırı]
Devir: [repo + hesaplar + export + temiz kurulum]
Karar sahibi: [iş + teknik + sözleşme sorumluları]

TankDev ile hangi noktadan başlayabilirsiniz?

Hazır ürünün işinizi karşılayıp karşılamadığından emin değilseniz önce kritik senaryoyu tarif edin. Özel yazılım yaklaşımımızı, web uygulamalarını ve sistem entegrasyonu kapsamını inceleyin. TankDev ile görüşürken yukarıdaki brief’i paylaşmanız, konuşmayı ekran sayısından iş sonucuna taşır. Projenizi anlatın; kapsamı, doğrulanacak riskleri ve ilk teslimin kanıtını birlikte değerlendirelim.

Kaynaklar ve daha ileri okuma

• OWASP ASVS — uygulama güvenliğini test edilebilir gereksinimlere dönüştürmek için.
• NIST SP 800-218 / SSDF 1.1 — güvenli geliştirme ve tedarikçi değerlendirmesinde ortak dil için.
• WordPress license — çekirdek yazılım lisansını hizmet ve işletim maliyetinden ayırmak için.