Archie vs Lovable: prototipler üretim duvarına çarptığında
Lovable uygulamanızı üretmenize yardım eder. Archie onu yayına almanıza ve ayakta tutmanıza yardım eder.
2026’da teknik olmayan kurucuların yazılım kurduğu herhangi bir topluluğa bakın, aynı karşılaştırmanın tekrar ettiğini göreceksiniz: Lovable mı, Archie mi? Doğru soru, çünkü yüzeyde iki araç birbirine yeterince benziyor ve aradaki farklar ancak uygulama gerçek kullanıcılar için gerçek iş yapmak zorunda kaldığında önem kazanıyor.
İşte dürüst, doğrudan bir karşılaştırma. İğneleme yok. Lovable, kurulduğu iş için iyi bir ürün. Soru şu: kurulduğu iş, gerçekten ihtiyaç duyduğunuz şeye karşılık geliyor mu?
Her biri ne için kuruldu
Lovable, yapay zekâ tabanlı bir ön yüz üreticisi. Temel deneyim bir komut yazmak, React ve Tailwind ile çalışan bir arayüz almak ve onu görsel olarak cilalamaktan oluşuyor. Sonuç gerçekten etkileyici: teknik olmayan biri dakikalar içinde ekranda uygulamaya benzeyen bir şeye sahip olabiliyor. Sahne arkasında Lovable, üretilen ön yüzü veritabanı ve kimlik doğrulama için Supabase ile bağlıyor; barındırmayı (genellikle Vercel ya da Netlify) müşterinin kendisinin bağlaması bekleniyor.
Archie, yapay zekâya doğal tam uygulama kurma aracı. Temel deneyim bir fikir yazmak, düzenli bir uygulama planı almak (modüller, kullanıcı tipleri, servisler, entegrasyonlar, veri modeli, mimari), bu planı değiştirmek ve uygulamayı ona göre üretmekten oluşuyor. Ön yüz, arka uç, programlama arayüzü ve barındırma tek bir ürüne ait. Arka uç, her Archie uygulamasıyla standart olarak gelen, GraphQL çevresinde kurulmuş bir BaaS servisi olan Archie Core.
İkisi de teknik olmayan kişilere ve küçük ekiplere yöneliyor. Fark, her birinin nerede durduğunda.
Lovable’ın gerçekten iyi olduğu yerler
Lovable’ın hiçbir şeyi iyi yapmadığını iddia etmek rahat olurdu. Özellikle üç alan var.
Ön yüz üretimi hızlı ve görsel olarak temiz. Lovable, çoğu mühendislik insanının ilk denemede teslim ettiğinden daha iyi görünen React ve Tailwind kodu üretiyor. Statik siteler, pazarlama sayfaları, hafta sonu prototipleri, satış gösterimleri ve görsel taslaklar için güzel bir sonuca varma hızı yüksek.
Görsel düzenleyici iyi. Üretilen uygulama üzerinde sürükleyerek değişiklik yapmak, canlı önizlemeyle birlikte, gerçek ve kullanışlı bir döngü. Tasarım ve ürün ekipleri bağlam değiştirmeden cilalayabiliyor.
Supabase entegrasyonu çalışıyor. Müşteri Supabase modelinde rahatsa ve arka uç olarak Postgres, kimlik doğrulama ve dosya depolamayı kullanmak istiyorsa, Lovable’ın kurduğu bağlantı makul. Supabase’i zaten bilen biri için sürtünmenin bir kısmı ortadan kalkıyor.
Görev “cuma gününe kadar bir toplantı için tıklanabilir prototip lazım” ya da “iletişim formu olan bir açılış sayfası lazım” ise, Lovable bunu iyi yapar.
Lovable’ın modeli nerede çatlıyor
Sürtünme, uygulama prototipten üretime geçtiğinde ortaya çıkıyor. Üç yapısal neden var.
Birincisi, Lovable ekrandan başlayıp geriye doğru çalışıyor. Veri modeli, altı ay sonra uygulamanın genişletilebilmesi için değil, görünen arayüzün bugün çalışması için şekillendiriliyor. Şema değişmek zorunda kaldığında (ki her zaman kalır), onu güvenle geliştirme işi aracın dışında kalıyor. Bu, bilinen “uygulama gösterimde çalıştı ama üçüncü kullanıcıda çatladı” örüntüsünü üreten boşluk; yani vibe coding’den sonra gelen araç kuşağının tam olarak var olma nedeni.
İkincisi, arka uç başka bir şirketin ürünü. Supabase iyi bir BaaS ama müşteri ondan sorumlu hale geliyor: şema göçleri, satır düzeyi güvenlik kuralları, kenar işlevleri, faturalandırma, gözetim, büyüme. Lovable bununla konuşan bir ön yüz üretiyor; geri kalan her şey müşterinin sorunu. Teknik altyapısı olan biri için sorun değil. Yapay zekâ uygulama oluşturucusunu tam da montaj işinden kaçınmak için seçmiş, teknik olmayan bir kurucu için model sızdırıyor.
Üçüncüsü, üretimi ayakta tutmak teslim edilenin parçası değil. Barındırma Vercel ya da Netlify üzerinden gidiyor, gözetim müşterinin bağladığı her neyse o, gözlemlenebilirlik onun sorumluluğunda ve uygulama gece üçte çatladığında üç ya da dört panelden hangisine gireceğini tahmin etmesi gerekiyor. Lovable’ın işi görünen uygulamada bitiyor. Onun çevresindeki ayakta tutma sistemi kapsam dışı.
Bunlar bir sonraki sürümde yamalanacak uygulama boşlukları değil. Mimarinin sonuçları: ön yüzden başlayan ve yığının geri kalanını birleştirmek için müşteriye bel bağlayan bir aracın sonuçları.
Archie nerede farklı
Archie tersi varsayım çevresinde kurulmuş: ürün uygulamanın kendisi, ekran değil.
Plan aşaması yapısal farkın kaynağı. Herhangi bir kod üretilmeden önce Archie düzenli bir plan üretiyor: uygulamanın hangi modüllere sahip olduğu, onunla hangi kullanıcı tiplerinin çalıştığı, hangi servis ve entegrasyonlara ihtiyaç duyduğu, veri modelinin neye benzediği, teknoloji yığınının ne olduğu. Plan değiştirilebilir. Ne kurulacağına dair bir sözleşme. Kod üretimi planın karşısında yapılıyor, ona paralel değil.
Arka uç uygulamayla birlikte teslim ediliyor. Archie üzerinde kurulan her uygulama, kimlik doğrulama, veri, depolama ve entegrasyonları kendi temel öğeleri olarak taşıyan, GraphQL çevresinde kurulmuş bir BaaS servisi olan Archie Core’u içeriyor. Müşteri Supabase’de proje açmıyor, onu ön yüze yapıştırmıyor ve şemanın uyumlu kalmasını ummuyor. Tek bir şema var; tek bir arka uç onu kullanıyor ve tek bir programlama arayüzü onu sunuyor.
Barındırma standart olarak dahil. Dağıtım, ortamlar, gözlemlenebilirlik: hepsi tek pakette. Müşterinin yanında yönetmesi gereken bir Vercel hesabı yok. Bir şey dikkat gerektirdiğinde tek bir yerde duruyor.
Sonuç, birinci günden gerçek bir programlama arayüzüne sahip. Arka uç Archie Core olduğu için uygulamadaki her işlem aynı zamanda bir GraphQL işlemi. Uygulama, ayrıca kadro kurulması gereken bir programlama arayüzü projesi olmadan, yayına alındığı andan itibaren ajanlara hazır.
Vibe coding sonrası kuşağı ilk dalgadan ayıran yapısal kaymalar bunlar. Archie, bu tezin baştan sona uygulanmış hali.
Yan yana bakış
| Boyut | Lovable | Archie |
|---|---|---|
| Başlangıç noktası | Komut → ekranlar | Fikir → plan → ekranlar ve arka uç |
| Ön yüz | React ve Tailwind, yapay zekâ üretimi | Yapay zekâ üretimi, plana göre kurulur |
| Arka uç | Müşteri Supabase’i kurar ve sürdürür | Archie Core, dahil |
| Programlama arayüzü yüzeyi | Supabase’in ürettiği REST ve RPC | Önce GraphQL, tam Eşitlik İlkesi |
| Barındırma | Müşteri Vercel ya da Netlify bağlar | Pakette |
| Şema geliştirme | Müşterinin işi, aracın dışında | Birinci sınıf, planın parçası |
| Üretim çıktısı | Standart olarak prototip düzeyi | Standart olarak üretim düzeyi |
| Kimin için tasarlandı | Gösterimler, prototipler, pazarlama uygulamaları, MVP’ler | Müşterilerin para ödeyeceği uygulamalar |
| Hedef kitle | Hızlı kuran teknik ve teknik olmayan kişiler | Gerçek uygulama kuran teknik olmayan kişiler ve ekipler |
Lovable’ı ne zaman seçmeli
Lovable, amaç görünür bir sonuca varma hızıysa ve uygulama hiçbir yük taşımıyorsa doğru cevap.
İki gün içinde bir toplantı için tıklanabilir prototip gerektiğinde, hafif işlevselliği olan bir pazarlama ya da açılış sayfası istediğinizde, satış için bir fikir gösterimi kurduğunuzda, para ödemeyen kullanıcılarda bir fikri sınadığınızda ya da Supabase’i zaten iyi bildiğinizde ve onun üzerine ön yüz koymanın daha hızlı bir yolunu istediğinizde Lovable’ı kullanın.
Bu durumlarda Lovable’ın müşteriye devrettiği montaj maliyeti gerçekten küçük, çünkü uygulama prototip aşamasından büyümeyecek.
Archie’yi ne zaman seçmeli
Archie, amaç müşterilerin kullanacağı gerçek bir uygulamaysa ve ekip yığını birleştirmekten sorumlu olmak istemiyorsa doğru cevap.
Uygulama tutarlı kalması gereken kullanıcı verisi tutacaksa, şema aylar ve çeyrekler boyunca gelişecekse, uygulama entegrasyonların ya da ajanların onu çağırabilmesi için gerçek bir programlama arayüzüne ihtiyaç duyuyorsa, ekipte hiç kimse Supabase yapılandırmasını ve Vercel dağıtımlarını üstlenmek istemiyorsa, bir yazılım ekibinin uygulamayı devralacağı ve mimarinin bu devri atlatması gereken bir gelecek senaryosu varsa ya da uygulama uzun vade için kuruluyorsa Archie’yi seçin.
Bu durumlarda Lovable türü bir aracın müşteriye devrettiği montaj maliyeti, başlangıçta kazanılan zamanı eninde sonunda fazlasıyla aşan, tekrar eden bir işletme vergisine dönüşüyor.
Nasıl göç edilir
Bazı ekipler Lovable ile başlıyor, sonra üretim yığınına ihtiyaç duyduklarını keşfediyor. Göç yolu açık ama önemsiz değil: Lovable’ın ürettiği ön yüz genellikle Archie’nin plan tabanlı yapısına taşınabiliyor ama Supabase şemasının gözden geçirilmesi, kimlik doğrulama modelinin Archie Core’un modeliyle uzlaştırılması ve her özel kenar işlevi ya da satır düzeyi güvenlik kuralının Archie’deki karşılığına eşlenmesi gerekiyor. İş gerçek; bu yüzden uygulamanın nereye varacağını ilk komuttan önce bilmek değerli.
Dürüst özet
Lovable ve Archie aynı ürün değil. İki farklı sorunun iki cevabı.
Lovable, bir şeyi ekrana en hızlı nasıl getiririm? sorusunun doğru cevabı. Archie, müşterilerin para ödeyeceği ve önümüzdeki yılı atlatacak bir uygulamayı nasıl yayına alırım? sorusunun doğru cevabı. Bir ekip için bunlar tek ve aynı soruysa, Archie’yi seçmeli. Ayrı sorularsa, ekip gerçekten sorduğu soruya karşılık gelen aracı seçmeli.
Hata, ikinci soru için Lovable’ı seçmek, sekiz ay sonra montaj maliyetinin bir projeye dönüştüğünü keşfetmek ve baştan başlamaktır.
Diğer karşılaştırmalar
Lovable, bu sorunun ortaya çıktığı birçok araçtan biri. Kümenin geri kalanı, aynı şekilde karşılaştırılmış:
Archie vs Bolt · Archie vs Base44 · Archie vs Replit · Archie vs Cursor · Archie vs v0 · Archie vs Supabase · Archie vs Vercel
Daha geniş savı vibe coding sonrasında ne var ve 2026’nın en iyi yapay zekâ uygulama oluşturucuları yazılarında bulabilirsiniz.
Sıkça sorulan sorular
Archie, Lovable’ın alternatifi mi? Evet, tek bir çekinceyle: Archie farklı bir işi hedefliyor. Lovable prototip üretimi için, Archie üretim uygulaması üretimi için eniyilenmiş. Amaç prototip değil gerçek bir uygulamaysa Archie bir alternatif. Amaç gerçekten sadece prototipse Lovable makul bir seçim olarak kalıyor.
Bir projeyi Lovable’dan Archie’ye taşıyabilir miyim? Evet ama tek tıkla göç değil. Lovable’ın ön yüzü Archie’nin plan tabanlı yapısına taşınabilir ama Supabase şemasının ve her özel arka uç mantığının Archie Core’daki karşılıklarına eşlenmesi gerekir. Göçü düşünen ekipler bunu kopyala yapıştır değil, gerçek ve sınırları belli bir proje olarak planlamalı.
Archie neden arka uç içeriyor da Lovable içermiyor? Lovable, arka uç olarak Supabase ile entegre olan bir ön yüz üreticisi olarak tasarlandı. Archie tam bir platform olarak tasarlandı; Archie Core, her uygulamayla teslim edilen, GraphQL çevresinde kurulmuş dahili arka uç. Arka ucu dahil etme mimari kararı, müşterinin sorumluluğunun nerede bitmesi gerektiğine dair farklı bir inancı yansıtıyor.
Barındırma ne olacak? Lovable, müşterinin kendi barındırmasını (genellikle Vercel ya da Netlify) bağlamasını bekliyor. Archie barındırmayı, dağıtımı ve ortamları tek pakette veriyor: müşteri bunları ayrıca kurmuyor.
Lovable, Archie’den daha ucuz mu? Liste fiyatı doğru karşılaştırma değil. Doğru karşılaştırma, gerçek bir uygulamayı ayakta tutmanın toplam maliyeti: Supabase planı, Vercel planı, yığını birleştirip sürdürmeye harcanan zaman ve uygulama prototip odaklı araçtan büyüdüğünde ortaya çıkan olası göç maliyeti. Archie’nin fiyatı tam platformu yansıtıyor.
Lovable’ı seçmek beni Supabase’e bağlar mı? Pratikte evet: Lovable’ın ürettiği kod arka uç olarak Supabase’i bekliyor. Sonradan arka uç değiştirmek önemsiz bir iş değil. Üretime yönelen ekiplerin ön yüz üreticisini seçmeden önce arka uç seçimini düşünmesi gerektiğinin mimari nedenlerinden biri bu.