Tek başına birden fazla ürün geliştirirken sistemi nasıl sade tutuyorum?
Çok ürünlü çalışma doğal olarak karmaşıklık üretir. Bunu sıfırlamak mümkün değil; ama aynı kararları tekrar tekrar vermeyi, araç değiştirmeyi ve aynı anda her şeyi aktif tutmayı engelleyen bir işletim sistemi kurulabilir.
Aynı anda birden fazla ürün geliştirmenin dışarıdan görünen tarafı heyecanlı: farklı fikirler, farklı domain'ler, farklı kullanıcı problemleri. İçeriden görünen tarafı ise daha az romantik. Her ürün ayrı backlog, ayrı bug, ayrı domain, ayrı deploy, ayrı mağaza, ayrı ödeme sistemi ve ayrı zihinsel bağlam demek.
Ordovia, Bookcrumb, Feedcrumb ve diğer deneyler üzerinde çalışırken asıl darboğazın kod yazma kapasitesi olmadığını tekrar tekrar gördüm. Darboğaz bağlam değiştirme maliyeti. Bir projeden diğerine geçtiğimde yalnızca repository değiştirmiyorum; ürünün neden var olduğunu, hangi kararların sabit olduğunu ve şu anda neyin önemli olduğunu da tekrar zihnime yüklüyorum.
Birden fazla ürün geliştirmek için daha fazla sistem kurmak değil, daha az karar vermek gerekiyor.
İlk hata: her projeyi ayrı bir evren yapmak
Yeni bir ürün başladığında yeni araç denemek çok çekici. Birinde Supabase, diğerinde Firebase, öbüründe farklı deploy sistemi, yeni task manager, yeni tasarım sistemi. Kısa vadede eğlenceli; uzun vadede her proje için ayrı operasyon kası geliştirmek anlamına geliyor.
Ben artık her projeyi aynı stack'e zorlamıyorum ama varsayılanları mümkün olduğunca sabit tutuyorum. İstisna kullanmak için gerçek bir neden arıyorum.
const defaults = { sourceOfTruth: "GitHub", frontend: "React + TypeScript when appropriate", deploy: "Cloudflare when it fits", backend: "Supabase unless product needs justify another choice", release: "explicit production gate",};Amaç teknoloji standardizasyonu uğruna dogma yaratmak değil. Aynı problemi beş farklı şekilde çözmemek.
Tek kaynak doğrusu olmadan çok ürün yönetilemez
AI agent'lar, Lovable preview'ları, local branch'ler, deployment panelleri ve mobil build'ler devreye girdiğinde aynı ürünün birkaç farklı gerçekliği oluşabiliyor. Bu yüzden benim için kod tarafında kaynak doğrusu GitHub.
const truth = { code: "GitHub", production: "deployed commit", productDecision: "explicit documented decision",};Bir agent'ın local worktree'sinde çalışan kod, GitHub'da yoksa benim için bitmiş değil. Production'da görünen bir şey GitHub'daki kaynakla eşleşmiyorsa önce bu uyuşmazlığı çözerim. Çünkü çok ürünlü sistemde “hangi sürüm gerçek?” sorusunun cevabı bulanıklaşırsa her şey yavaşlar.
Ürün portföyü ile aktif iş listesi aynı şey değil
Bir insanın beş ürüne sahip olması aynı anda beş ürünü aktif geliştirmesi gerektiği anlamına gelmiyor. Bu ikisini uzun süre karıştırdığınızda portfolio zenginliği operasyon kaosuna dönüşüyor.
Ben bugün ürünleri zihnimde farklı statülere ayırmayı daha yararlı buluyorum.
type ProductState = | "primary" | "active-secondary" | "maintenance" | "experiment" | "paused";Primary ürün günlük derin çalışma alır. Active-secondary sınırlı kapasite alır. Maintenance yalnızca bug, kritik operasyon ve gerekli güncellemeleri alır. Experiment zaman kutulu olmalıdır. Paused ise gerçekten durmalıdır; görünmez bir backlog olarak her gün zihinsel RAM tüketmemelidir.
Öncelik sırası açık değilse en yeni fikir kazanır
Solo çalışmanın tehlikelerinden biri kimsenin sizi yeni fikirden uzaklaştırmaması. Yeni fikir daha heyecanlıdır, mevcut üründeki zor bug'dan daha temiz görünür ve hızlı dopamin üretir. Eğer önceden belirlenmiş ürün sırası yoksa çalışma planını duygusal enerji belirler.
Öncelik sistemi yoksa roadmap'i strateji değil, o gün en ilginç görünen şey yönetir.
Bu yüzden hangi ürünün ana ürün olduğunu açık tutmak gerekiyor. Yeni fikir bunu değiştirmek istiyorsa bir karar gerekir; sessizce araya girmesine izin vermemek gerekir.
Ortak mimari, kopyala-yapıştır repo demek değil
Birden fazla ürününüz olduğunda ortak bir starter kit kurmak mantıklı görünebilir. Ama çok erken ortak package sistemi yaratmak da yeni bir platform projesine dönüşebilir. Ben önce tekrar eden kararları standardize etmeyi, ancak gerçekten tekrar eden kod varsa ortaklaştırmayı tercih ediyorum.
| Ortaklaştır | Her üründe ayrı bırak |
|---|---|
| Release ilkeleri | Ürün domain modeli |
| Repo / branch doğrulama | Kullanıcı akışları |
| SEO temel checklist | Marka dili |
| Auth güvenlik prensipleri | Özel veri ilişkileri |
| Agent çalışma protokolü | Ürüne özgü UI |
Yani reuse önce davranış ve süreç seviyesinde başlıyor. Kod seviyesi reuse ancak gerçekten kanıtlanmış tekrar varsa geliyor.
AI hızı portföy kaosunu büyütebilir
AI coding araçları bir ürünü başlatmanın maliyetini çok düşürdü. Bu iyi bir şey. Aynı zamanda yeni ürün başlatmayı fazla kolay hale getirdi. Eskiden üç günlük prototip sürtünmesi sizi bir fikri düşünmeye zorluyordu; şimdi birkaç saat içinde çalışan arayüz oluşabiliyor.
Bu nedenle AI çağında fikir filtresi daha önemli. Kod üretimi ucuzladıkça “bunu yapabilir miyim?” sorusunun değeri azalıyor; “bunu sürdürmek istiyor muyum?” sorusunun değeri artıyor.
function shouldStart(product: Idea) { return ( product.problemIsClear && product.userIsClear && product.canReachValidationFast && product.hasMaintenanceBudget );}Her ürün için maintenance bütçesi var
Bir ürün yayınlandığında proje bitmiyor. Domain yenileme, backend, dependency, store policy, support, kullanıcı verisi, billing ve güvenlik sorumluluğu başlıyor. Bu görünmez bakım maliyeti yeni ürün kararının içinde olmalı.
Bu yüzden yeni bir ürünün MVP'sini bir haftada çıkarabiliyor olmak, onu bir yıl boyunca taşımanın bedava olduğu anlamına gelmiyor.
const productCost = buildCost + hostingCost + supportCost + maintenanceCost + attentionCost;Benim için son terim genellikle en pahalı olanı: attentionCost.
Release kapılarını bilinçli tutuyorum
Birden fazla repository ve platform olduğunda her push'ın otomatik production veya store release üretmesi teoride verimli görünüyor. Pratikte ise yanlış branch, hatalı env veya eksik acceptance daha hızlı yayılabiliyor.
Bu nedenle özellikle mobil build, store release, migration ve kritik production operasyonlarında manuel tetikleme benim için sürtünme değil, kontrol katmanı.
const automationPolicy = { lint: "automatic", test: "automatic", preview: "automatic when useful", databaseMigration: "explicit", storeRelease: "explicit",};Yeni araç eklemek varsayılan olarak hayır
Ürün sayısı arttıkça tool-switching maliyeti katlanıyor. Her projede farklı analytics, farklı deploy paneli, farklı task manager veya farklı AI workflow kullanmak zihinsel adres uzayını büyütüyor.
Yeni bir araç ancak mevcut sistemde ölçülebilir bir problemi çözüyor ve yeni bakım yüzeyi yaratmaya değiyorsa eklenmeli. “Daha iyi olabilir” tek başına yeterli neden değil.
Yeni araç kullanmak ilerleme değildir. Eski bir sürtünmeyi gerçekten kaldırıyorsa ilerlemedir.
Backlog'ları birleştirmiyorum, karar sistemini birleştiriyorum
Bütün ürünleri tek devasa backlog'a koymak bana yararlı gelmiyor. Her ürünün kendi bağlamı var. Fakat hangi backlog'un bugün attention alacağını belirleyen üst seviye karar sistemi ortak olmalı.
type WeeklyPortfolioDecision = { primaryProduct: string; primaryOutcome: string; secondaryMaintenance: string[]; explicitlyNotDoing: string[];};Özellikle explicitlyNotDoing alanı önemli. Çünkü solo çalışmada yapılmayacak şeyleri yazmazsanız hepsi zihinsel olarak aktif kalıyor.
Küçük ürünlerde aynı gün frontend, backend, pazarlama ve support yapabilirsiniz
Solo builder olmanın doğası rol değiştirmektir. Bunu tamamen ortadan kaldıramazsınız. Ama gün içindeki mikro geçişleri azaltabilirsiniz. Ben benzer işleri gruplayıp mümkün olduğunda bir bağlamı birkaç saat korumayı daha verimli buluyorum.
| Bağlam | Örnek işler |
|---|---|
| Build | Kod, bug, refactor, test |
| Product | Scope, akış, öncelik, UX kararı |
| Release | Build, store, migration, deploy |
| Growth | Site, içerik, listing, outreach |
Bu bir zaman yönetimi numarası değil; context reload sayısını azaltma yöntemi.
Bir ürünün sistemden çıkabilmesi de tasarlanmalı
Her ürün sonsuza kadar aktif kalmamalı. Bir deney doğrulanmadıysa pause veya archive kararı da sistemin normal parçası olmalı. Yoksa portföy yalnızca büyür ve her yeni proje mevcut tüm projelerin üzerine eklenir.
if (!signal && maintenanceCost > learningValue) { product.state = "paused";}Bırakmak başarısızlık değil. Düşük sinyalli bir üründen attention geri almak, güçlü ürüne yeniden yatırım yapmaktır.
Benim sade sistemim
- Bir ana ürün açıkça belirlenir.
- Diğer ürünlere aktif-secondary, maintenance, experiment veya paused statüsü verilir.
- GitHub kod için kaynak doğrusudur.
- Teknoloji ve servislerde varsayılanlar korunur; istisna gerekçelendirilir.
- Migration ve store release gibi riskli işler bilinçli kapılardan geçer.
- AI agent'lara farklı roller verilir ama ürün kararı insanda kalır.
- Yeni ürün başlamadan maintenance bütçesi hesaba katılır.
- Her hafta yapılacaklar kadar yapılmayacaklar da belirlenir.
Sonuç
Tek başına çok ürün geliştirmek mümkün. AI araçları, managed backend'ler ve modern deployment platformları bunu geçmişe göre çok daha erişilebilir yaptı. Ama üretim kapasitesinin artması attention kapasitesini artırmıyor.
Bu yüzden benim sistemimin amacı daha fazla proje açabilmek değil. Açtığım projelerin birbirini sabote etmesini engellemek.
const soloPortfolio = { ideas: "many", activePriorities: "few", sourceOfTruth: "one", exceptions: "expensive", attention: "finite",};Çok ürünlü çalışma ancak bu son satırı kabul ettiğinizde sadeleşmeye başlıyor: attention sonsuz değil. Sistemin geri kalanı bu kıt kaynağı korumak için var.