2. Gün — Faturalama Sisteminin Entegre Edilmesi (ve UI’nın Geri Getirilmesi)

Bu makalede, backend’in derinliklerinde başlayan ve UI’nin nihayetinde uyum sağladığı bir süreci ele alıyoruz.

Sorun

GraceSoft Hikayesi, commit’leri zaman çizelgelerine dönüştürme yolu olarak başladı.

Zaman çizelgeleri tek başına bir ürün değildir.

Bu zamanı gerçek hale getirmek için ihtiyaç duydum:

• faturalama
• planlar
• özellik erişim kontrolü

Kod tabanını, if (plan === 'pro') karmaşasına dönüştürmeden.

Adım 1 — Planlar Kodda Yaşanmamalı

İlk kaldırdığım şey:

refactor(plans): remove implicit plan seeding
    

Planlar, migration veya seeder’larda olmamalıdır.

Onlar Stripe‘da yer almalıdır.

İçsel olarak planları tanımlamak yerine, Stripe’ı gerçek kaynağım haline getirdim.

Adım 2 — Stripe → Uygulama Senkronizasyonu

feat(stripe): store product details when syncing catalog
    

Artık ürünler ve fiyatlandırmalar yerel olarak senkronizasyondan sonra yaşıyor.

Bu, hızlı sorgular, özellik eşleştirimi ve Stripe API’sine olan çalışma zamanı bağımlılığını ortadan kaldırır.

Adım 3 — Abonelik Modelleme

feat(billing): integrate account-plan-subscription schemas
    

Tipik kısayoldan (örneğin: user.plan) kaçındım.

Bunun yerine:

• hesaplar
• planlar
• abonelikler

Bu, takımlar, paylaşılan faturalama ve her hesap için birden fazla repo gibi durumlar için esneklik sağlıyor.

Adım 4 — Stripe Eşleştirme Sorunu

fix(stripe): persist subscriptions using metadata tier mapping
    

Stripe uygulamanızın mantığını bilmez.

Bu nedenle, metadata kullanarak şunları eşledim:

• Stripe ürünleri → içsel seviyeler

Bu, ad eşleştirme gibi kırılgan varsayımları önler.

Adım 5 — Özellik Gating’ini Veri Olarak Kullanma

feat(plans): add pricing-gated feature schema
    feat(stripe): refresh plan gates from catalog tier updates
    

Sabit kodlama yerine:

if ($user->plan === 'pro')
    

Artık şunlara sahibim:

• özellik tanımları
• planlara bağlı
• dinamik olarak senkronize edilmiş

Bu şekilde sistem, “Bu hesap bu özelliğe erişime sahip mi?” sorusunu yanıtlayabilir.

Adım 6 — Olay Tabanlı Faturalama

feat(api): add stripe and postmark webhook endpoints
    

Faturalama durumu artık:

• asenkron
• olay tabanlı
• tutarlı

Artık kullanıcı tetiklenmiş güncellemelere bağlı kalmıyoruz.

Adım 7 — Dağılmadan Önce Belgele

docs(readme): replace template with project documentation
    

Şu başlıkları içeriyor:

• mimari
• faturalama akışı
• şemanın kararları

Adım 8 — Tasarım Yönü Öncelikli

UI’ye dalmadan önce, tonu belirledim:

chore(ui): add design inspiration
    

Şu yönlere eğilimliyim:

• pre-glass macOS hissi
• yapılandırılmış, sakin arayüzler
• narratif öncelikli düzen

Adım 9 — UI Uyum Sağlıyor

feat(ui): implement app shell and redesign core story pages
    

Sonunda:

• uygulama kabuğu yerinde
• hikaye sayfaları yeniden tasarlandı
• düzen “zaman çizelgesi olarak hikaye” fikriyle uyumlu hale geldi

Bugün Ne Değişti

• Faturalama artık bir düşünce değil
• Planlar dışsallaştırıldı
• Özellikler yapılandırılmış veriler haline geldi
• UI, sisteme uyum sağlıyor

Özellikle:

Sistem artık kimin hangi hikaye parçasını görme yetkisine sahip olduğunu anlıyor.

Son Düşünce

Bugün dikkat çekici özelliklerden ziyade, kısayolların kaldırılmasına odaklanıldı.

Çünkü faturalama işin içine girdiği anda, şu soruları yanıtlamak zorundasınız:

• Ne değerlidir?
• Ne kısıtlıdır?
• Ne hikayenin parçasıdır?

Yarın:

• UI + API üzerinden özellik kapılarını zorlamak
• kullanım → fiyatlandırma bağlantısı
• kilitli özellikler etrafında kullanıcı deneyimini iyileştirmek

Benzer bir şey inşa ediyorsanız,
özellik kapılarını alan mantığınızda nasıl yapılandırıyorsunuz?