Bir ürün ikiye dönüştüğünde: yapay zekayla geliştirdiğin uygulamayı sıfırdan başlamadan nasıl bölersin

Tek bir fikirle başladın. Onu yapay zeka uygulama oluşturucuna anlattın, ekranları üretmesini izledin, pürüzleri düzelttin ve gerçek bir şey yayınladın. İnsanlar kullanmaya başladı. Ve sonra, önce yavaşça, geri bildirimlerde bir örüntü belirdi: kullanıcılarının yarısı bir şey istiyordu, diğer yarısı başka bir şey. Aynı özellik için kavga etmiyorlardı. İki farklı ürün istiyorlardı.

İşte bu, birçok kurucunun panikleyip sıfırdan ikinci bir proje başlattığı andır. Başlatmamalılar. Tek ürünün aslında iki olduğu ortaya çıktığında bir yapay zeka uygulamasını bölmenin daha temiz bir yolu var — ve bu yol genellikle zaten geliştirdiğinin çoğunu korur. Bu yazı, bölünmeyi nasıl tanıyacağına, ne zaman yapacağına ve bölünmenin aldığı üç biçime dair.

İki ürünün olduğunu nasıl anlarsın

Sinyal neredeyse hiçbir zaman bir özellik talebi gibi görünmez. Sürtünme gibi görünür.

Bunu yaşadığını izlediğim bir verimlilik uygulamasının net bir hikâyesi vardı. “Kişisel planlayıcı” olarak satılıyordu. Kullanıcılar iki türde belirmeye başladı. Bir grup kendi haftasını planlamak için kullanıyor ve onu özel bir not defteri gibi görüyordu. Diğer grup küçük ekipler yönetiyordu ve işleri başkalarına atamak istiyordu. İkisi de aynı ürünü kullanmaya devam edecek kadar memnundu, ama her sürüm bir grubu memnun edip diğerini rahatsız ediyordu. Ekip bir özellik önceliklendirme sorunları olduğunu düşündü. Aslında bir marka sorunları vardı. Bir kişisel uygulamaları ve bir ekip uygulamaları vardı; tek bir kod tabanını, tek bir ana sayfayı ve tek bir fiyatlandırma sayfasını paylaşıyorlardı.

Şunlardan biri doğru olmaya başladığında o çizgiyi aştığını anlarsın:

Açılış sayfan, iki kitle aynı sözlere inanmayacağı için gerçek vaadini genel ifadelerin arkasına gizlemek zorunda kalıyor.
Her yeni özelliğin “ama diğer tür kullanıcı için farklı çalışmalı” şartı var.
Destek yanıtların dallanmaya başlıyor: “eğer onu kendin için kullanıyorsan…” ve “eğer bir ekip yönetiyorsan…”
Önemli sayıda kullanıcı, iki modu ayrı tutmak için iki ayrı hesap tutuyor.

Bunlardan iki ya da daha fazlasını görüyorsan, bir özellik sorunun yok. Olmayı bekleyen bir ürün bölünmen var.

Bölünmenin üç biçimi

Ilk gün bir biçim seçmek zorunda değilsin. Genellikle önce en hafifini deneyip yükseltebilirsin. Ama onu yapay zeka oluşturucuna anlatmaya başlamadan önce menüyü bilmek faydalıdır, çünkü kullandığın kelimeler üretileni şekillendirir.

Biçim 1: Tek uygulama, iki kapı

En hafif sürüm. Tek bir kod tabanı tutarsın. İlk açılışta bir soru eklersin — “Buraya kendin için mi yoksa bir ekip için mi geldin?” — ve cevabı, farklı bir sayfa kümesi ve farklı bir navigasyon göstermek için kullanırsın. Aynı veri deposu. Aynı giriş. Aynı faturalama. Sadece farklı bir yüzey.

Çoğu yapay zeka uygulama oluşturucu, onu “iki modlu uygulama” olarak anlatırsan bunu iyi yönetir. Dikkat edilmesi gereken şey, iki modun her yerde koşullu göster-gizle’lerle dolu ekranları paylaşmaması. Bu, iki gibi davranan kalabalık tek bir uygulama gibi görünür. Oluşturucuya iki kapının ayrı olduğunu söyle — farklı ana sayfalar, farklı ayar sayfaları, farklı boş durumlar. Gerçekten örtüşen birkaç ekran (hesap ayarları, faturalama) paylaşılabilir.

Bu ne zaman işe yarar: iki kitle farklı bir çerçeve ama aynı temel nesneleri istediğinde. Planlayıcı-ekip örneği buraya uyar. Planladığın şey hâlâ bir görevdir; sadece atama, paylaşma ve bildirim kuralları değişir.

Bu ne zaman işe yaramaz: iki kitle tamamen farklı nesneler beklediğinde. Bir “müşteri portalı” ile bir “kurum içi yönetim aracı”, aynı işle ilgili görünseler bile neredeyse hiç örtüşmez.

Biçim 2: İki uygulama, tek backend

Ortadaki biçim. Ürünün önyüzünü iki ayrı uygulamaya bölersin — iki URL, iki açılış sayfası, iki katılım akışı, iki fiyatlandırma tablosu — ama ikisi de aynı veritabanından okur. Bir müşterinin ikisinde de hesabı olabilir. Bir yönetici ikisinin de verisini görebilir.

Bu, bu blogu yöneten şirkette yakın zamanda yaptığımız şey. İki kitleye hizmet etmeye çalışan tek bir uygulamamız vardı: agent platformumuzu değerlendiren mühendisler ve yapay zeka uygulama oluşturucumuzu kullanan üreticiler. Aynı backend, aynı kimlik doğrulama, aynı veritabanı — ama önyüz iki başlı hale gelmişti ve mesaj kafa karıştırıcıydı. Onu her kitle için bir tane olmak üzere iki önyüz uygulamasına böldük. Backend tam olarak aynı kaldı.

Bu biçim şu durumlarda doğru cevaptır:

İki kitle farklı nedenlerle satın alıyor.
Diğer kitlenin pazarlama metni karşısında kafaları karışır ya da soğurlar.
Önemsedikleri veri çoğunlukla aynı şekle sahip ama farklı çerçevelenmiş.
İki veritabanı ya da iki faturalama kurulumu yönetmek istemiyorsun.

Yapay zeka oluşturucuna “mevcut API’yi paylaşan ikinci bir önyüz uygulaması” istediğini söyle. Çoğu modern yapay zeka oluşturucu kardeş bir proje kurabilir ve onu mevcut backend’ine yönlendirebilir. Kaçınılması gereken tuzak: ilk uygulamanın bileşenlerini olduğu gibi kopyalayıp-yapıştırmak ve sonra her iki kopyayı sonsuza dek düzenlemek. Oluşturucudan paylaşılan kısımları (kimlik doğrulama ekranları, ortak form araçları) her iki uygulamanın da kullandığı küçük bir kütüphaneye çıkarmasını iste. Sonradan aylar süren mükerrer düzeltmelerden kendini kurtarırsın.

Biçim 3: İki uygulama, iki backend

En ağır bölünme. Aslında iki ürünün var. Veri paylaşmıyorlar, kullanıcı paylaşmıyorlar ve bir yol haritası paylaşmamalılar. Doğru hamle onları tamamen ayırmaktır: ayrı kod tabanları, ayrı veritabanları, ayrı alan adları.

Bu, insanların düşündüğünden daha nadiren doğru hamledir. Cazip gelir çünkü temiz hissettirir. Gerçek şu ki, tamamen ayrı iki uygulama, çalışır tutmak için her şeyden iki tane demektir — iki dağıtım hattı, iki nöbet rotasyonu, iki faturalama entegrasyonu, iki yardım belgesi. Ürünler gerçekten örtüşmediği sürece bu biçime uzanma. İyi bir test: A ürününün bir kullanıcısı B ürününün bir kullanıcısı asla olmayacaksa, muhtemelen Biçim 3’e ihtiyacın var. Kullanıcılarının çoğu makul biçimde ikisini de isteyebilirse, neredeyse kesinlikle Biçim 2’yi istiyorsun.

Bunu bir yapay zeka oluşturucuyla yaptığında en kolay hamle, ikinci proje için mevcut projeni bir başlangıç noktası olarak kopyalamak, sonra oluşturucudan ait olmayan özellikleri kaldırmasını ve ait olanları eklemesini istemektir. İkinci projeye boş bir tuvalden başlama. İlkini geliştirirken zaten çok şey öğrendin ve izin verirsen yapay zeka oluşturucu o bağlamı alır.

Bir şeyi bölmeden önce ne yapmalı

Bölünmeyi yapay zeka oluşturucuna anlatmadan önce üç küçük şey yap. Kulağa geldiğinden daha değerliler.

Önce, her taraf için yeni ana sayfayı yaz. Her biri iki paragraf. Vaat, kitle, yapmalarını istediğin tek şey. İki farklı ana sayfa yazamıyorsan, henüz iki ürünün yok demektir — sadece tek bir ürünün iki segmenti var ve bunu mimariyle değil, mesajla çözmelisin.

İkinci, hangi ekranların paylaşıldığını ve hangilerinin paylaşılmadığını listele. Dürüst ol. “Giriş paylaşılıyor. Katılım farklı. Panel farklı. Ayarlar çoğunlukla paylaşılıyor. Faturalama paylaşılıyor.” Bu liste, yapay zeka oluşturucuya verdiğin brief olur. Çok fazla gidip gelmeyi önler.

Üçüncü, altta neyin aynı olduğuna karar ver. Aynı kullanıcılar mı? Aynı veri mi? Aynı ödemeler mi? Her “evet” seni Biçim 1 ya da 2’ye çeker. Her “hayır” seni Biçim 3’e çeker. Doğru cevap yok — sadece ürününün gerçekte nasıl çalıştığına uyan cevap var.

Bölünmeden sonra ne değişir

İki şey kolaylaşır, bir şey zorlaşır.

Pazarlama kolaylaşır. Her uygulama kendi net vaadini alır. Her açılış sayfası, çekince koymadan tek bir kitleye seslenebilir. Dönüşüm oranın genellikle en az bir tarafta, bazen ikisinde de yükselir.

Katılım kolaylaşır. İlk kez gelen bir kullanıcı, herkesle ilgili olmaya çalışan bir sayfaya değil, kendisiyle ilgili bir sayfaya iner.

Zorlaşan şey, paylaşılan kısımları senkronize tutmaktır. Giriş akışındaki bir hatayı düzeltirsen, onu her iki uygulamada da düzeltilmiş istersin. Faturalama ekranının görünümünü değiştirirsen, her iki uygulamanın da bunu yansıtmasını istersin. İhtiyacın olan disiplin — ve bu, ister bir yapay zeka oluşturucuyla vibe coding yapıyor ol ister bir insan geliştirici ekibiyle geliştiriyor ol, doğrudur — paylaşılan kısımları gerçekten paylaşılan tutmaktır. Kopyalama. Çatallama. Ya paylaşılan ekranı her iki uygulamanın da kullandığı küçük bir kütüphaneye çıkar, ya da gerçekten ayrı iki uygulaman olduğunu kabul et ve ona sahip çık.

Bitirmek için küçük bir soru

Mevcut uygulamanın vaadini beş yabancıya gösterip her biri onu farklı tanımlasaydı — ama iki ayrı kovada — muhtemelen zaten bölünmeyle yaşıyorsundur. Tek soru, tek bir kafa karıştırıcı ürünün vergisini ödemeye devam mı edeceğin, yoksa iki ürün olduğun konusunda dürüst olmanın işini mi yapacağın.

Bugün karar vermek zorunda değilsin. Ama bir dahaki sefere yapay zeka uygulama oluşturucun “sırada ne geliştireyim?” diye sorduğunda, en faydalı cevabın yeni bir özellik olmayabileceğini düşün. Yeni bir ön kapı olabilir.

Bu sana hitap ettiyse, daha önceki yazımız ekibin için geliştirmek ile müşteriler için geliştirmek de hoşuna gidebilir — aynı türden karar, ürününün hayatında bir adım daha erken.