| name | Audit Plans Limits Monetization |
| description | Comprehensive audit of the SKAPARA subscription plans, usage limits, and monetization system. Use when asked to audit pricing, plans, usage limits, free tier, premium features, Stripe subscriptions, chat/design daily limits, upsell flows, or the €9.99/month plan. Covers server-side limit enforcement, bypass prevention, guest vs authenticated limits, and chatbot upsell behavior when limits are reached.
|
Audit Plans, Limits & Monetization
Systematic audit of SKAPARA's monetization strategy — free tier limits, premium plan, Stripe integration,
and the upsell pipeline through the AI chat interface.
Prerequisites
- Read
CLAUDE.md for Stripe and Supabase client patterns
- Read
frontend/src/app/api/ai/chat/route.ts for chat endpoint and limit enforcement
- Read
frontend/src/lib/stripe/ for Stripe integration
- Read the Supabase schema for usage tracking tables (
user_usage, subscriptions, etc.)
- Search for "limit", "usage", "plan", "subscription", "premium" across the codebase
Workflow
Phase 1: Plan Definition & Pricing
-
Plan structure:
- Search for plan/pricing definitions (pricing page, config file, DB table)
- Identify all tiers: free (guest), free (registered), premium (€9.99/month)
- What features does each tier include? Document the feature matrix
- Check: is the €9.99 price defined in one place or scattered?
- Check: is pricing localized for different currencies/regions?
-
Pricing page:
- Find the pricing/plans page (search
src/app/[locale] for pricing, plans, subscription)
- Is it well-designed? Clear value proposition?
- Does it show feature comparison between tiers?
- CTA buttons: what do they link to? (Stripe checkout? registration?)
- Mobile layout: does the pricing page work on 375px?
- i18n: is pricing text translated in all locales?
-
Plan configuration:
- Where are plan limits defined? (env vars? config file? DB? hardcoded?)
- Are limits centralized or duplicated across multiple files?
- Check for magic numbers (hardcoded
5, 10, etc. without named constants)
Phase 2: Usage Tracking
-
Usage storage:
- Find the usage tracking mechanism (search for
user_usage, usage, daily_count)
- How is usage stored? (Supabase table? Redis? in-memory? cookies?)
- Schema: what fields exist? (user_id, date, chat_count, design_count, etc.)
- Is usage tracked per day? per month? rolling window?
- How is the "day" boundary defined? (UTC midnight? user timezone?)
-
Guest usage tracking:
- How are unregistered users identified? (IP? fingerprint? cookie? localStorage?)
- Can guests clear cookies/storage to reset their limit? → BYPASS VULNERABILITY
- Are guest limits enforced server-side or only client-side?
- Check: what prevents a guest from making unlimited API calls directly?
-
Authenticated usage tracking:
- Is usage tied to
auth.uid()?
- Is the usage counter incremented atomically? (race condition check)
- Can a user with multiple sessions/devices bypass limits?
- Is there a usage reset mechanism (daily cron? on-read check?)
Phase 3: Limit Enforcement
-
Chat limits:
- Read the chat API route — where is the limit check?
- Is the limit check BEFORE the AI call? (don't waste API credits)
- Guest limit: 5 chats/day — is this enforced?
- Registered free limit: X chats/day — what's the number? is it enforced?
- Premium: unlimited or higher limit? — verify
- Check: is the limit check in middleware, route handler, or utility function?
- Check: can the limit be bypassed by calling the API directly (curl)?
-
Design generation limits:
- How many designs per day for each tier?
- Is the limit checked before calling the image generation API?
- Are failed generations counted against the limit?
- What happens when a design partially generates then fails?
-
Limit response behavior:
- When a user hits the limit, what HTTP status is returned? (429? 403? custom?)
- What message does the user see?
- Does the AI chatbot itself know about limits and respond appropriately?
- Does the chatbot mention the premium plan when limits are reached?
- Is there a countdown/remaining-uses indicator in the UI?
Phase 4: Stripe Integration
-
Subscription creation:
- How does a user subscribe? (Stripe Checkout? embedded form? in-app?)
- Read the subscription creation endpoint
- Is the Stripe Price ID correct for €9.99/month?
- What happens after successful payment? (webhook? redirect? session update?)
- Check: is the user's plan status updated in Supabase after payment?
-
Subscription lifecycle:
- Can users cancel? How? (in-app? Stripe portal? email?)
- What happens on cancellation? (immediate? end of period?)
- Is there a grace period?
- How are failed payments handled? (dunning? status downgrade?)
- Renewal: automatic? notification before renewal?
-
Stripe webhooks:
- Read webhook handler (search for
stripe-webhook, webhook)
- Which events are handled? (checkout.session.completed, invoice.paid, subscription.deleted, etc.)
- Is webhook signature verified? (CRITICAL for security)
- Is webhook processing idempotent? (replay protection)
- What happens if the webhook fails? (retry? dead letter?)
-
Subscription status checks:
- How does the app check if a user is premium?
- Is it checked on every request or cached? (stale status risk)
- What field in the DB indicates premium status?
- Can a user fake premium status? (client-side check only → CRITICAL)
Phase 5: Upsell & Engagement
-
Upsell triggers:
- When does the app suggest upgrading? (limit hit? feature gate? proactive?)
- Is the upsell message in the chat natural and non-intrusive?
- Does the chatbot know about the plan details (price, features)?
- Is there an in-chat upgrade button/link?
- Does the upsell adapt to locale (€ vs $ vs language)?
-
Feature gating:
- Which features are premium-only? List them all
- How are premium features gated in the UI? (hidden? disabled? teaser?)
- Is gating consistent between frontend and backend?
- Check: can premium features be accessed via API without subscription?
-
Conversion optimization:
- Is there a free trial? (X days free, then charge)
- First-purchase discount or introductory price?
- Social proof on pricing page (X users subscribed, testimonials)
- Urgency/scarcity tactics (limited time offer?)
- Email drip after hitting limits
Phase 6: Security & Integrity
-
Limit bypass prevention:
- Can limits be bypassed by:
- Clearing cookies/localStorage (guests)?
- Using incognito mode?
- Calling API directly without UI?
- Manipulating request headers (spoofed user ID)?
- Using multiple accounts?
- Are ALL limit checks server-side?
- Is the usage counter in a protected DB table with RLS?
-
Subscription fraud:
- Can someone share a premium account?
- Is there device/session limiting for premium?
- Can a user subscribe, use heavily, then chargeback?
- Are Stripe webhook secrets properly stored (not hardcoded)?
Output Format
Write the report to audit-ecommerce-2026-03-07/08-plans-limits-monetization.md (or the directory specified by the user):
# SKAPARA Plans, Limits & Monetization Audit — [DATE]
## Executive Summary
[2-3 sentences: monetization readiness, biggest risks, revenue impact]
## Findings
### Phase 1: Plan Definition & Pricing
| # | Finding | Severity | File:Line | Recommendation |
|---|---------|----------|-----------|----------------|
| PLM-01 | ... | CRITICAL/HIGH/MEDIUM/LOW | path:line | ... |
### Phase 2: Usage Tracking
...
### Phase 3: Limit Enforcement
...
### Phase 4: Stripe Integration
...
### Phase 5: Upsell & Engagement
...
### Phase 6: Security & Integrity
...
## Plan Feature Matrix
| Feature | Guest (Free) | Registered (Free) | Premium (€9.99/mo) |
|---------|-------------|-------------------|---------------------|
| Chat messages/day | 5 | X | Unlimited |
| Design generations/day | 0 | X | X |
| ... | ... | ... | ... |
## Limit Enforcement Audit
| Limit | Server-Side | Bypassable | Atomic | Notes |
|-------|-------------|------------|--------|-------|
| Guest chat | YES/NO | YES/NO | YES/NO | ... |
...
## Stripe Integration Checklist
| Check | Status | Notes |
|-------|--------|-------|
| Webhook signature verified | OK/FAIL | ... |
| Idempotent processing | OK/FAIL | ... |
| Subscription status sync | OK/FAIL | ... |
...
## Scorecard
| Category | Score /10 | Notes |
|----------|-----------|-------|
| Plan Design | X | ... |
| Limit Enforcement | X | ... |
| Stripe Integration | X | ... |
| Upsell Flow | X | ... |
| Security | X | ... |
## Priority Action Items
1. [P0] ...
2. [P1] ...
Severity Levels
- CRITICAL: Limit bypass allowing unlimited free usage, subscription fraud, missing webhook verification → revenue loss
- HIGH: Inconsistent limits, broken upsell flow, stale subscription status → impacts monetization
- MEDIUM: Missing upsell opportunities, poor pricing page, no usage visibility → reduces conversion
- LOW: Polish items, better messaging, analytics improvements
