Bandruption

The agentic operating layer for the music industry — helping artists grow, monetize, and operate their careers with AI.

Comment

Bandruption

Inspiration

The music industry has plenty of tools, but artists and fans still experience them as disconnected products: subscriptions in one place, fan engagement somewhere else, AI tools somewhere else, and campaign spending somewhere else again.

Bandruption is building an agentic operating layer for the music industry. For Shipaton, we focused on the commercial layer underneath that idea: creating one system where fans can subscribe, music professionals can unlock AI-powered services, and users can buy BANDS, Bandruption's closed-loop platform currency.

The goal was not simply to add a subscription screen. We wanted RevenueCat to become the monetization infrastructure connecting subscriptions, entitlements, paywalls, virtual currency, web, mobile, and our own backend.

What we built

Bandruption now has a RevenueCat-backed monetization architecture spanning both fans and music professionals.

Our RevenueCat catalog includes:

  • Superfan monthly and annual subscriptions
  • Fan AI monthly and annual subscriptions
  • Music Pro BYOAI monthly and annual subscriptions
  • Music Pro Managed AI monthly and annual subscriptions
  • Six consumable BANDS packs
  • Multiple entitlements that independently control fan, AI, professional, commission, and annual-plan benefits
  • RevenueCat Offerings and managed paywalls for the different audiences

On the web, a user can begin with an intent such as becoming a Superfan, purchasing Fan AI, or buying BANDS. If they are not authenticated, Bandruption preserves that intent through signup/sign-in and then presents the appropriate RevenueCat paywall.

On mobile, we integrated RevenueCat's native SDK and RevenueCatUI so the same customer identity and entitlement system can be used across platforms.

That identity consistency is important: web purchases, mobile purchases, entitlement checks, restores, virtual currency, and backend webhook events all resolve to the same Bandruption user.

BANDS: virtual currency with a real backend

One of the most interesting parts of the project is BANDS.

BANDS are designed to be campaign fuel inside Bandruption. Fans can use them to participate in the ecosystem, while music professionals can ultimately use them for things such as AI usage, promotion, campaigns, and bounties.

RevenueCat Virtual Currency handles the commercial BANDS balance and consumable purchases. Bandruption maintains its own append-only transaction ledger as an audit and application-side mirror.

When RevenueCat sends a VIRTUAL_CURRENCY_TRANSACTION, our webhook processes each BAND adjustment and records it idempotently in our ledger.

We deliberately do not credit purchased BANDS from the client. The client initiates the purchase, but fulfillment happens through the authenticated server-side RevenueCat event.

The wallet can then reconcile against RevenueCat's live balance while retaining a local history and fallback state.

How we built it

The application is primarily TypeScript and uses a shared monorepo architecture across the web platform, mobile application, backend services, database, and shared packages.

For RevenueCat specifically, we built:

  • RevenueCat Web Billing using @revenuecat/purchases-js
  • Native mobile purchases and paywalls with RevenueCat and RevenueCatUI
  • RevenueCat Offerings mapped to Bandruption product tiers
  • Entitlement-based access control
  • RevenueCat Virtual Currency integration for BANDS
  • Server-side webhook processing
  • HMAC webhook verification
  • Durable webhook idempotency
  • An append-only BANDS transaction ledger
  • Balance reconciliation between RevenueCat and Bandruption
  • Shared subscription and RevenueCat schemas
  • Read-only catalog verification tooling against RevenueCat's APIs
  • Tests for purchase routing, webhook retries, invalid signatures, duplicate events, multiple virtual-currency adjustments, and balance behavior

Our production architecture intentionally separates responsibilities.

RevenueCat owns the commercial state: products, subscriptions, offerings, paywalls, entitlements, purchases, and virtual-currency transactions.

Bandruption owns the music-industry state: users, artists, permissions, campaigns, bounties, AI usage rules, audit history, and the actions that an entitlement allows someone to perform.

That boundary turned out to be one of the most important architectural decisions in the project.

Challenges we faced

Cross-platform identity

A purchase system becomes much harder when web and mobile must behave like one product. Anonymous purchases would have created separate RevenueCat customers and made entitlement and BANDS reconciliation unreliable.

We therefore make authenticated Bandruption user IDs the RevenueCat App User ID across the system.

Webhooks must be safe to retry

Payment systems retry events. Networks fail. Processes restart.

We could not treat a webhook as something that would arrive exactly once.

Our webhook processing uses durable event claims and transaction-level identifiers so repeated delivery does not repeatedly grant currency or subscription state.

Catalog identifiers become infrastructure

We discovered that product and entitlement identifiers are not cosmetic. Once an identifier has existed in an external billing system, changing it can have consequences.

One example was an older RevenueCat entitlement reserving the superfan lookup key. We standardized the active entitlement as fan_superfan and updated the application to treat the canonical identifier as part of the contract between RevenueCat and our backend.

Virtual currency is more than a balance

A number on a screen is easy. A currency that can be purchased, granted, consumed, refunded, audited, and eventually used by AI agents is not.

We needed to think about idempotency, authoritative balances, ledger history, failure recovery, refund behavior, and how future usage-based AI spending will reserve and consume BANDS safely.

What we learned

The biggest lesson was that monetization infrastructure is fundamentally a distributed systems problem.

The paywall is the visible part. The harder problem is keeping the store, RevenueCat, authentication system, database, webhook processor, mobile app, web app, and product permissions in agreement.

RevenueCat allowed us to avoid rebuilding the parts of that system that should be standardized — catalog management, purchases, subscription state, offerings, paywalls, entitlements, and virtual currency — while still keeping Bandruption-specific business logic under our control.

That has also changed how we think about new products. A new paid capability no longer needs a new billing system. It can become another entitlement, offering, BANDS-funded action, or experiment inside the same commercial layer.

What's next

The next step is connecting BANDS consumption directly to Bandruption's AI usage pipeline, allowing AI usage and overages to be metered against the same wallet.

We also plan to expand the RevenueCat-backed model deeper into our agentic music platform: AI promotion workflows, artist campaigns, fan bounties, and other actions where a user's subscription and available BANDS determine what their agents are authorized to do.

The result we are working toward is simple from the user's perspective:

Subscribe once. Buy fuel when you need it. Then let Bandruption help you actually do the work.

Built With

Share this project:

Updates

Submission history