Stylify Financial Launch Readiness Audit

1

Billing Infrastructure

🔴 Blocker

Stripe Integration Status Unknown

We do not have documented, verified confirmation that Stripe is wired up correctly and that subscription billing actually works end-to-end. No evidence of:

Live (non-test) Stripe account credentials
Subscription creation endpoint test
Trial-to-paid transition test
Payment confirmation in production
Webhook handling validation

Impact: We cannot legally accept money if we don't know subscription billing works. Customer charges could fail silently. Founding members could get access without payment.

Action Required (This Week): Stitch must verify Stripe integration end-to-end:

Test account signup → 14-day trial starts → day 15 automatic charge occurs
Verify monthly subscription created in Stripe dashboard
Verify webhook handling (payment_intent.succeeded, customer.subscription.updated)
Document findings in DECISIONS.md

If any step fails, it's a show-stopper until fixed.

🔴 Blocker

Founding Member Tier Pricing Logic Not Verified

Founding members should be billed at $49/mo (monthly) or $39/mo (annual) for full Pro access. The pricing logic that:

Identifies a user as a "founding member"
Charges them the discounted price instead of $99/mo
Locks that price in permanently
Grants them Pro features

...has not been documented as implemented or tested.

Impact: We could charge founding members the wrong price, or charge them Pro pricing when they should be locked at Solo pricing. Revenue is instantly wrong on Day 1. Legal exposure if we over-charge and can't refund cleanly.

Action Required (This Week): Stitch must verify founding member pricing:

Identify where founding member status is stored (users table column?)
Verify Stripe subscription creation passes correct price ID ($49 or $39 depending on billing period)
Test: Create 2 founding member accounts, verify they're charged $49/$39, verify they get Pro features
Verify lock-in mechanism (price can't change if they cancel/resubscribe)
Document in DECISIONS.md

🔴 Blocker

Trial-to-Paid Conversion Path Not Documented

Every new user gets a 14-day free trial with full Pro access. After 14 days, we must:

Automatically start charging them based on their chosen tier
Downgrade features to match their tier (if they chose Solo, remove auto-publishing)
Either succeed and send confirmation, or fail and escalate

There is no documented end-to-end test showing this works, no known failure handling, and no escalation path if the charge fails.

Impact: Users could remain in trial indefinitely. Stylify doesn't bill them. Or they could be billed unexpectedly with no notice. Support load spikes on Day 15 post-launch with "why was I charged?" complaints. Churn during conversion.

Action Required (This Week): Stitch must verify trial-to-paid conversion:

Document the exact flow: trigger (time-based job?), payment attempt, success/failure handling
Create a test user, verify trial-to-paid happens on day 15
Test both success (card accepted) and failure (card declined) scenarios
Verify feature downgrade happens correctly if user chose Solo
Implement email notification for successful transition (or escalate to Jason)
Document in DECISIONS.md

🔴 Blocker

Annual Billing Not Fully Implemented

We offer annual pricing at 20% discount: Solo $39/mo ($468/yr), Pro $79/mo ($948/yr), Salon $159/mo ($1,908/yr). There is no evidence of:

UI checkbox/toggle for "pay annually" during signup/checkout
Stripe price IDs created for annual billing intervals
Founding member annual pricing ($39/mo = $468/yr)
Annual billing in tier selection flow

Impact: Users can only choose monthly billing. We lose the 20% margin boost from annual customers. Missing the founding member annual option means we're leaving $39/user money on the table. Customer expectation gap — most SaaS offer annual discounts.

Action Required (Before Launch): Stitch must implement annual billing:

Create Stripe price IDs for all annual plans (6 total: Solo/Pro/Salon × monthly/annual)
Add annual billing toggle/radio to tier selection (Step 3 of onboarding or checkout)
Verify logic switches price IDs based on selection
Test founding member annual pricing ($39/mo)
Verify annual subscription auto-renews at end of year

🔴 Blocker

Dunning Emails Not Built

When a subscription payment fails (e.g., card declined, insufficient funds), we need a recovery sequence:

Email 1 (immediate): "Your payment failed. Click to update payment method."
Email 2 (day 3): "Your payment is still pending. Access suspended in 3 days."
Email 3 (day 6): "Your subscription has been cancelled due to unpaid payment."

These emails are not built. Stripe webhooks aren't connected to any email system.

Impact: First payment failure = instant churn. Customer sees access removed with no explanation. No recovery path. Revenue loss of up to ~$600/month per churned founding member. Repeat this across 100 founding members and we're at $60K/year in preventable churn.

Action Required (Month 1 Post-Launch): Stitch + Charlotte collaboration:

Stitch: Wire Stripe webhook events to Kit API (customer.subscription.payment_failed, invoice.payment_failed)
Charlotte: Write 3 dunning emails (recovery-focused, not guilt-based)
Stitch: Auto-tag users in Kit when payment fails (e.g., tag "payment-failed")
Kit: Create automation sequence triggered by tag
Test end-to-end: simulate failed charge, verify emails send, verify feature access suspended

This is lower priority than Day 1 billing verification but should launch before opening to public (handle founding members first).

🔴 Blocker

Cancellation Flow Not Implemented

According to the ToS (Section 17.7, approved 02-20):

No refunds for mid-period cancellations
Access retained through end of billing period
Subscription automatically cancels at renewal

But we don't have:

Cancel button in the app
Confirmation screen with refund policy callout
Cancellation reason collection (for analytics)
Subscription cancellation in Stripe
Feature retention through period end
Email confirmation of cancellation

Impact: Users request cancellation → we have no mechanism to do it → support tickets → manual Stripe cancellations → inconsistency in treatment → chargeback risk. Also, we lose the chance to collect win-back data ("why are you leaving?").

Action Required (Month 1 Post-Launch): Stitch + Charlotte:

Stitch: Add "Cancel Subscription" button to Settings page (hidden until user has active subscription)
Add confirmation modal showing: "You'll lose access on [date]. No refund for partial periods." with reason dropdown
Call Stripe API to cancel subscription at current period end (don't charge next cycle)
Send confirmation email with final access date
Charlotte: Write cancellation email (acknowledge loss, offer win-back)
Tag user in Kit for win-back sequence when they cancel

🔴 Blocker

Refund/Chargeback Policy Not Formalized

We say "no refunds" in the ToS, but we don't have:

Formal chargeback dispute response template
Process for evaluating refund exceptions (e.g., duplicate charge, billing error)
Appeals process if customer disputes "no refund"
Stripe account configured to respond to chargebacks
Staff training on when refunds are legally required (ROSCA, state laws)

Impact: Customer requests refund → we say "no" → customer initiates chargeback → Stripe automatically deducts charge + $15 fee + account damage. At scale, even a 2-3% chargeback rate can trigger Stripe account review/suspension. We're also exposed to state consumer protection laws (some states require trial refunds).

Action Required (Before Launch or Month 1): Charlotte + Jason:

Charlotte: Document refund policy exceptions (e.g., "We'll refund if you request within 7 days of trial charge").
Add exceptions to ToS.
Create chargeback response template for Jason (points to trial offer, ToS, etc.).
Research state-specific refund requirements (CA, NY, IL at minimum).
Stitch: Ensure Stripe disputes are logged in app analytics so Jason can track.

2

Cost Structure & Infrastructure Spending

🔴 Blocker

Supabase Free Tier Auto-Pause Risk

Supabase warned (Feb 15) that the project `etsacubwnujenvbpekwm` would auto-pause due to inactivity. Current mitigation: keep-alive script (`setInterval` pings every 4 hours) added to server.js. This is a temporary bandage.

Free tier has no backup, no SLA, 1GB DB limit
Keep-alive script is a hack — could fail silently
Production data at risk
Unacceptable for paying customers

Impact: One production crash during customer data import = lawsuit. We can't accept paying users on a free tier database. If keep-alive fails and DB pauses, all signup/login/content fails. Founding members can't use the product. Revenue = $0 that month.

Action Required (ASAP - Target ~March 1): Stitch:

Upgrade Supabase to Pro ($25/mo)
This requires entering a credit card in Supabase dashboard (Jason may need to do this)
Verify upgrade succeeds, keep-alive can be removed
Pro includes: daily backups, 8GB DB, 250GB bandwidth, SLA, 24/7 support
Remove keep-alive script from server.js after upgrade

Cost: $25/mo. ROI: First paying customer ($49/mo solo or $99/mo Pro) covers this 2-4x over.

🟡 Important

API Cost Scaling Uncertainty

Current estimate: $0.07/user/month for Claude Haiku + GPT-4o-mini (fallback). This assumes:

1 post per day per user
Single pass through Claude for caption + context
Occasional fallback to OpenAI

But real costs depend on:

How many users retry/regenerate captions (not 1 per day, could be 2-3)
Whether we add photo analysis (increases per-post cost)
Whether carousel posts (3-5 captions) are common
Fallback rate to OpenAI (Haiku availability issues?)

Impact: If average cost is actually $0.15/user (2x estimate), then:

100 founding members = $15/month in API costs (vs. estimated $7)
1,000 users = $150/month (vs. estimated $70)

Margins still excellent (96%+), but we need to know actual rate to avoid surprises.

Action Required (Month 1 Post-Launch): Stitch + Jason:

Set up cost tracking in Anthropic dashboard + OpenAI dashboard (sync weekly)
Log actual per-request costs in analytics (tokens used × rate)
After 50 founding members, calculate actual cost per user vs. estimate
If actual > $0.12/user, investigate: regeneration rate? carousel frequency? fallback rate?
Update financial dashboard with real rates

🟡 Important

Infrastructure Costs at Scale Not Modeled

Current hosting: Railway (backend, $5-20/mo usage-based) + Vercel (frontend, free tier). Supabase (free → $25 Pro). At 100 users, this is fine. But if we scale to 1,000 users:

Railway: Could be $50-200/mo depending on CPU/memory
Supabase: Pro may not scale — might need to upgrade to Team plan (~$600+/mo)
Vercel: Free tier has limits (50GB/month bandwidth, build time) — could exceed and bill
Resend (email): Free tier is 100/day (might hit limits)
Kit (email): $39/mo at 10K subscribers, but growth beyond requires paid tier

Impact: Low in first 90 days (under 500 users), but we should know the scaling curve. At 1,000 users:

Infrastructure costs could reach $1,000+/mo
With blended ARPU $79/mo, we need ~13 users just to cover infrastructure
No surprise bill shock if we grow fast

Action Required (Month 1-2 Post-Launch): Mint + Stitch:

Create 3-tier infrastructure cost model: 100 users, 500 users, 1,000 users
Identify upgrade points (when to move from free to paid in each service)
Monitor actual usage weekly and model forward
Update financial dashboard with scaling scenarios

🟢 Post-Launch

ElevenLabs Voice Cloning Cost ($22/mo)

ElevenLabs Creator plan ($22/mo) is allocated for demo video voice narration (cloning Jason's voice). Not yet purchased. Once videos are produced, this cost recurs indefinitely.

Impact: Very low. $22/month is trivial against revenue. Only relevant if we stop using demo videos or voice cloning.

Action (Post-Launch): Jason signs up for ElevenLabs Creator plan after recording voice clone script. Cost justified if videos drive 5+ users/month (payback in 1 month).

🟢 Post-Launch

Descript ($24/mo) May Be Deferred

Descript was used for Meta screencast video editing (v1-v4 scripts). Once Meta approves, Descript may not be needed unless we continue making product demo videos.

Impact: Low. If we cancel Descript, we save $24/mo. If we keep it for ongoing demo production, it's justified.

Decision (Post-Launch): Revisit after Meta approval. If we're not producing new demo videos, cancel Descript.

3

Revenue Capture & Growth Model

🔴 Blocker

Landing Page → Signup → Payment Flow Not End-to-End Tested

We need to verify: User lands on getstylify.com → clicks "Try Free" → enters email → chooses tier (Solo/Pro/Salon) → **optionally chooses annual billing** → enters card info → trial starts → day 15 trial ends → payment charged.

There's no documented full-funnel test. Multiple pieces exist but may not wire together:

Landing page copy and "Try Free" CTA (exists)
Signup form (exists but may not have tier/annual selection)
Stripe checkout (exists but not verified)
Trial setup (exists but not verified)
Trial-to-paid transition (not verified)

Impact: Huge. If signup flow is broken, no founding members can sign up. $0 revenue on Day 1. Launch is dead.

Action Required (This Week): Stitch (lead) + Jason:

Stitch: Walk through signup flow end-to-end:
1. Navigate to stylify-ai.com
2. Click "Try Free" or "Start Free Trial"
3. Enter email, password
4. Select tier (Solo, Pro, or Salon)
5. Select billing period (monthly or annual)
6. Enter card info (use Stripe test card 4242 4242 4242 4242)
7. See confirmation "Your 14-day trial starts now"
8. Login and verify you have correct features
9. Verify subscription created in Stripe dashboard
10. Verify trial end date in app
Document all screenshots in DECISIONS.md with "VERIFIED" label
Test with both Solo and Pro tiers
Test annual billing at least once

If any step fails, fix before launch.

🟡 Important

Referral Program Not Built (But Planned for Month 1)

Referral logic exists in DECISIONS.md (3-for-1: 3 referred users = 1 free month for referrer), but the implementation is deferred to Month 1 post-launch. This means founding members can't refer in the first 30 days.

Impact: Low in first 30 days. Stylists are great at word-of-mouth — we're leaving early referral momentum on the table. But it doesn't block launch.

Action (Month 1 Post-Launch): Stitch implementation brief is in inbox. Build: referral link generation, referral tracking, coupon auto-creation, success confirmation email. Charlotte: write referral email template.

🟡 Important

100 Founding Member Cap Not Enforced in Code

We want to fill exactly 100 founding member spots at Pro-for-Solo pricing ($49/mo). After 100, new users get Solo at $49/mo or Pro at $99/mo (normal pricing). But the codebase doesn't have:

Counter tracking how many founding members have signed up
Logic to flip "accept founding members" flag to false after 100
Messaging to tell users "founding members sold out" if they arrive after 100
Safeguard against accidentally selling 101st founding member at $49

Impact: We could accidentally give founding pricing to user #101, #102, etc. Each extra founding member at $49 instead of $99 = $50/month revenue loss. Scale this to 110 users (10 over cap) = $500/month forgone. Or we manually track in a spreadsheet and miss it.

Action Required (Before Launch): Stitch:

Add `founding_member_count` to admin dashboard
Create logic: on every user signup, increment counter if billing_tier='founding'
When counter reaches 100, set feature flag `founding_members_closed=true`
On signup form: if flag is true, hide founding member option
Email Jason when counter hits 90, 95, 100 so he can decide if offer closes or extends
Log this to DECISIONS.md: "Founding member enforcement implemented"

🟢 Post-Launch

Retention Email Sequences Not Built (But Planned for Day 1)

Retention automation (4-tier inactivity sequence + monthly recap + upsell) is in the inbox as a task for Stitch but not yet built. It's planned for Day 1 post-launch (or shortly after).

Impact: Low in first week but critical by week 2. Without retention emails, inactive founding members don't get re-engaged. Churn starts higher than it could be.

Action (Day 1 Post-Launch): Stitch builds retention automation. Charlotte writes emails.

4

Financial Controls & Transparency

🟡 Important

Real-Time Revenue Dashboard Missing

There is a static Financial Dashboard (.xlsx, updated manually). But there's no real-time view of:

Revenue captured this month (vs. plan)
Churn rate and MRR impact
Active subscription count by tier
Failed payment attempts
Customer acquisition cost (CAC)
Lifetime value (LTV) by cohort

Currently, Jason would have to log into Stripe dashboard manually.

Impact: Medium. Jason can't see revenue glance at a glance. If churn suddenly spikes, no early warning. If a payment processor issue silently fails payments, we won't know for days.

Action (Month 1 Post-Launch): Stitch:

Add admin dashboard page: "Revenue This Month"
Queries:
- SUM(amount) from successful Stripe charges this month
- Count of active subscriptions by tier
- Count of churn this month
- Failed payment attempt count
Email Jason weekly with summary (template in inbox)

🟡 Important

No Fraud Detection or Suspicious Transaction Alerts

We're accepting credit cards via Stripe. Red flags to watch for:

Bulk account creation + immediate signup (bot attack?)
Multiple failed payment attempts from one card
Same card used to create 5+ accounts
Chargeback-prone card patterns (high-risk countries, prepaid cards)
Founding member signups with test cards (4242 4242 4242 4242, etc.)

We have no alerting for these.

Impact: Low first 30 days (small user base), but medium at scale. A coordinated card-testing attack could process 100+ charges before we notice. Stripe fraud tools help, but we should log anomalies.

Action (Month 1 Post-Launch): Stitch:

Log signup events to analytics: email, card last-4, payment status
Flag and email Jason if:
- Same card creates 3+ accounts in 1 day
- Same email + multiple cards (5+ cards in 1 week)
- Card matches known test patterns (Stripe has a list)
Enable Stripe Radar for fraud detection (free in Stripe dashboard)

🟢 Post-Launch

Monthly Financial Reconciliation Process Not Defined

No process for: "Once a month, verify Stripe revenue matches app revenue matches bank deposit."

Impact: Low in first 90 days, but essential as we scale. Prevents silent revenue leaks.

Action (Month 2 Post-Launch): Mint + Jason:

Create monthly reconciliation checklist:
1. Export Stripe revenue report
2. Query app database for successful charges
3. Compare: should be equal
4. Check bank deposit matches Stripe payout
5. Log any discrepancies
Mint to own this task (spreadsheet + checklist)

5

90-Day Cash Flow Projection

Assumptions:

• Meta approval: ~March 5, 2026
• Founding member launch: ~March 6
• Target: 100 founding members acquired over ~30-60 days
• Distribution: 70% monthly billing ($49/mo), 30% annual ($39/mo, 12-month prepay)
• No existing revenue (pre-launch)
• Churn: Assumed 0% in first 30 days (founding effect), then ramping
• CAC: $0 for founding (organic/direct channels)

Month	Period	Founding Members Added	Active Subscriptions	Monthly Revenue	Annual Prepay (one-time)	Total Revenue
Month 1	March 6-31	35	35	$1,715	$425	$2,140
Month 2	April 1-30	50	85	$4,165	$608	$4,773
Month 3	May 1-31	15 (cap reached)	100	$4,900	$0	$4,900
90-Day Total Revenue					$11,813

Operating Costs Over 90 Days:

Cost Category	Monthly	3-Month Total	Notes
Supabase Pro	$25	$75	Upgraded from free (~March 1)
Railway Backend	$15	$45	Estimate: $5-20 at 100 users
Claude API (Haiku)	$49	$147	$0.07/user × avg 70 users
OpenAI API (fallback)	$10	$30	~10% of Haiku volume
Kit (ConvertKit) Email	$0	$0	Free tier (10K subs, 1 sequence)
Domain (getstylify + stylify-ai)	$2.50	$7.50	~$30/year prorated
ElevenLabs (if active)	$22	$66	For demo video voice cloning (optional)
Resend (transactional email)	$0	$0	Free tier (100 emails/day)
Vercel (frontend)	$0	$0	Free tier (unlikely to exceed limits)
Total Operating Costs (without ElevenLabs)	$123.50	$370.50
Total Operating Costs (with ElevenLabs)	$145.50	$436.50

90-Day Profit (Excluding Stripe Fees & Founder Salary):

Scenario	Revenue	Costs	Gross Profit	Profit Margin
Conservative (no ElevenLabs)	$11,813	$371	+$11,442	96.8%
With ElevenLabs	$11,813	$437	+$11,376	96.3%

Adjustments Not Included: Stripe processing fees (2.2% + $0.30/transaction = ~2.5% of revenue, or ~$295 on $11,813), which would reduce net profit to ~$11,100 and margin to 94%. Still highly profitable. Also not included: Jason's salary/draw, taxes, contractor costs (none expected in 90 days), or customer refunds.

Key Insight: The economics are extremely attractive. We break even on month 1 (before Stripe fees) and are profitable by week 4-5. The constraint is not profitability; it's user acquisition. If we fill 100 founding members in 60 days, we're at ~$5K/month recurring after day 90. This is a strong signal that the product works and customers pay.

6

Risk Scenarios & Mitigation

🟡 Important

Scenario: 100 Users Sign Up on Day 1 (Viral Effect)

Unlikely but possible if Jason shares launch in a high-engagement community (salon owner group, etc.). What breaks?

Supabase: Pro tier ($25/mo) supports 100 concurrent users. We're OK.
Railway: $5-20/mo tier has 512MB RAM. 100 users × 2MB session state = ~200MB used. Should handle, but close.
Claude API: If 100 users all generate captions simultaneously, we'll hit rate limits. API will reject requests.
Stripe: No limits, processes fine.
Email: Resend free tier can send 100 emails/day. 100 users = 100 confirmations + welcome emails = exhausts limit on day 1.

Impact: Users experience degraded service (slow loads, API errors, welcome email doesn't send). Complaints spike. Churn risk if onboarding fails. Revenue is captured but user experience is bad.

Action (Pre-Launch & Day 1):

Stitch: Pre-load test with 100 concurrent requests to generation endpoint to identify breaking point
Stitch: Implement request queuing + backpressure (if Claude queue > 50, return "busy, try again" instead of erroring)
Stitch: Set up Sentry alerts for error rate spikes (threshold: > 5% fail rate)
Jason: On Day 1, monitor Sentry/logs every 30 min for first 4 hours
If Claude rate limit hits, Stitch has fallback to OpenAI (already in code)
If Resend limit hits, Stitch can manually send welcome emails or switch to Kit (but would require coordination)
Have Stripe phone number ready in case charge processing has issues

🟡 Important

Scenario: API Costs Spike Unexpectedly

What if actual cost is $0.20/user/month instead of $0.07? This could happen if:

Users regenerate captions 3-4x per post (we estimate 1x)
Carousel posts are common (3 captions instead of 1)
Photo analysis is enabled (adds tokens per request)
Claude API becomes unavailable and we heavily lean on OpenAI (3x cost)

At $0.20/user × 100 users = $20/month cost (vs. estimated $7). Still fine, but at 1,000 users it becomes $200/month vs. $70.

Impact: Low in first 90 days (margin stays 90%+). But if we scale to 1,000 users and costs are 3x estimate, we're burning more than expected. We'd need to either optimize prompts, charge more, or limit usage.

Action (Week 1 Post-Launch):

Stitch: Log every API call with token count used
Calculate actual cost per user after 7 days, 14 days, 30 days
If actual cost > $0.12/user, investigate: regeneration rate? carousel frequency?
If pattern confirmed, optimize:
- Reduce context window if possible
- Switch more carousel to GPT-4o-mini (cheaper for long output)
- Implement caching (same photo gets same suggestion)

🟡 Important

Scenario: Chargeback or Refund Rate Spikes

If 2-3 founding members request refunds or initiate chargebacks:

Stripe processes chargeback, deducts $49 + $15 fee = $64 loss per chargeback
3 chargebacks = $192 loss
If pattern continues, Stripe could flag account for review (high chargeback rate = increased risk)
We have no formal refund policy beyond "no refunds" (which may not hold up legally)

Impact: Low financially (3 chargebacks = $192 loss is trivial against $12K revenue), but reputational if it's due to product failure. If chargeback rate > 1% (>1 per 100 charges), Stripe may investigate or increase processing fees.

Action (Pre-Launch & Month 1):

Stitch: Monitor Stripe chargeback rate weekly
If user requests refund: Jason has authority to approve for users who sign up and don't log in (low friction, acknowledges we haven't provided service)
Charlotte: Document refund exception policy in ToS (e.g., "Refund within 7 days if no posts generated")
If chargeback happens: Stitch files dispute with Stripe (we have proof of service delivery)

🟢 Post-Launch

Scenario: Supabase Database Corruption or Data Loss

Free tier has no backups. Pro tier has daily backups but limited restore window. If a migration or deployment breaks the database, we'd be looking at manual recovery.

Impact: Low first 90 days (only founding members, data replaceable), but medium at scale. 100 users' posts lost = lawsuit.

Action (Month 1 Post-Launch):

Stitch: Implement daily backup export (SQL dump to S3) on top of Supabase's backups
Test restore from backup monthly

🟢 Post-Launch

Scenario: Founding Member Churn (30-50% in Month 2-3)

Founding member retention is unpredictable. Early adopters have high expectations. If 40% churn by day 60:

100 founding members → 60 active by day 90
Revenue: 60 × $49 + 40 × $39/12 (annual cohort amortized) = ~$3K/month (instead of $5K)
We've still built a business but with slower early traction

Impact: Medium. Lower revenue signal but not a blocker. Stylify still works; we just need to optimize retention or improve onboarding.

Action (Ongoing):

Retention automation (emails, health scoring) built Day 1 to maximize retention
NPS survey at 7 days to identify churn reasons early
Win-back sequences for cancellations

7

Missing Items & Open Questions

🟡 Important

No Payment Method Updating UI

Users need a way to update their credit card in the app (in Settings). Currently, there's no way for a user to change their card if it's expiring or if they want to switch cards. They'd have to email Jason.

Impact: Churn risk. If user's card expires and they can't update it, they can't pay. We'd miss that subscription renewal and contact them for payment.

Action (Before Launch or Month 1): Stitch:

Add "Update Payment Method" button in Settings
Click opens Stripe-hosted payment form (Stripe Billing Portal)
User updates card without leaving app

🟡 Important

Invoice/Receipt System Not Documented

When a user is charged, do they get a receipt? Where do they find it? Stripe auto-generates receipts, but we don't have:

Link to Stripe receipt in settings
Receipt email from Resend or Stripe
In-app invoice history

Impact: Medium. Users need receipts for tax purposes or expense reports. If they can't find it, they contact support. Also, invoice is a touchpoint to reinforce value ("You paid $49 for 30 days of 2-min posts!").

Action (Month 1 Post-Launch): Stitch + Charlotte:

Stitch: Add "Billing History" page to Settings (lists past charges, links to Stripe invoice PDFs)
Add "Invoice" button on Stripe receipts that opens PDF
Charlotte: Write receipt email template (sent by Stripe webhook)

🟡 Important

No Documentation of Stripe Account Configuration

We should have a document showing:

Stripe product IDs (what's a "Solo" product ID in Stripe?)
Price IDs for each tier × billing (6 total)
Webhook endpoints configured (which events go to which URLs?)
Customer sync logic (when we create a user, do we create a Stripe customer?)
Coupon/discount configuration
Tax settings (are we configured for sales tax?)
Payout settings (where does money go?)

Impact: Medium. If Stitch leaves or is unavailable, we have no handoff documentation for Stripe integration. If there's an issue, we're debugging blind.

Action (Before Launch): Stitch:

Document in DECISIONS.md or a new "Stripe Configuration Guide":
List all Stripe IDs, webhook endpoints, configuration choices
Include screenshot of Stripe dashboard with key pages

🟢 Post-Launch

No Tax/Compliance Setup

We're in the US (or targeting US market). We should understand:

Are we collecting/remitting sales tax? (Likely yes, varies by state)
Are we VAT/GST compliant if we get international customers?
Do we need to report to IRS for 1099 contractors (we have none now, but may later)?
What's our tax entity structure (sole proprietor, LLC, etc.)?

Impact: Low first 90 days (all US customers, no tax liability if B2B SaaS in certain states). Medium at scale or if international customers arrive.

Action (Month 2 Post-Launch or Before Scaling): Jason + Accountant:

Determine sales tax obligation in primary states (look at Stripe settings — may auto-collect if configured)
If needed, set up sales tax remittance
Stripe Tax can auto-calculate and collect if enabled

8

Quick Reference: All Findings by Priority

Priority	Finding	Owner	Deadline
🔴 BLOCKER	Stripe Integration Status Unknown	Stitch	This Week (2/24-2/28)
🔴 BLOCKER	Founding Member Pricing Logic Not Verified	Stitch	This Week (2/24-2/28)
🔴 BLOCKER	Trial-to-Paid Conversion Path Not Documented	Stitch	This Week (2/24-2/28)
🔴 BLOCKER	Annual Billing Not Fully Implemented	Stitch	Before Launch
🔴 BLOCKER	Dunning Emails Not Built	Stitch + Charlotte	Month 1 Post-Launch
🔴 BLOCKER	Cancellation Flow Not Implemented	Stitch + Charlotte	Month 1 Post-Launch
🔴 BLOCKER	Refund/Chargeback Policy Not Formalized	Charlotte + Jason	Before/Month 1 Post-Launch
🟡 IMPORTANT	Supabase Free Tier Auto-Pause Risk	Stitch	ASAP (~March 1)
🟡 IMPORTANT	Landing Page → Payment Flow Not End-to-End Tested	Stitch + Jason	This Week (2/24-2/28)
🟡 IMPORTANT	API Cost Scaling Uncertainty	Mint + Stitch	Month 1 Post-Launch
🟡 IMPORTANT	Infrastructure Costs at Scale Not Modeled	Mint + Stitch	Month 1-2 Post-Launch
🟡 IMPORTANT	100 Founding Member Cap Not Enforced in Code	Stitch	Before Launch
🟡 IMPORTANT	Real-Time Revenue Dashboard Missing	Stitch	Month 1 Post-Launch
🟡 IMPORTANT	No Fraud Detection or Suspicious Transaction Alerts	Stitch	Month 1 Post-Launch
🟡 IMPORTANT	No Payment Method Updating UI	Stitch	Before Launch or Month 1
🟡 IMPORTANT	Invoice/Receipt System Not Documented	Stitch + Charlotte	Month 1 Post-Launch
🟡 IMPORTANT	No Documentation of Stripe Account Configuration	Stitch	Before Launch
🟢 POST-LAUNCH	Referral Program Not Built	Stitch + Charlotte	Month 1 Post-Launch
🟢 POST-LAUNCH	Retention Email Sequences Not Built	Stitch + Charlotte	Day 1 Post-Launch
🟢 POST-LAUNCH	ElevenLabs Voice Cloning Cost	Jason	Post-Launch (optional)
🟢 POST-LAUNCH	Descript Subscription May Be Deferred	Jason	Post-Launch (optional)
🟢 POST-LAUNCH	Monthly Financial Reconciliation Process	Mint	Month 2 Post-Launch
🟢 POST-LAUNCH	Tax/Compliance Setup	Jason + Accountant	Month 2+ Post-Launch

9

Mint's Assumptions & Uncertainties

Key Assumptions Made in This Audit:

1. Stripe is the payment processor. DECISIONS.md mentions Stripe, but there's no definitive confirmation that the account is live and credentials are in place. I'm assuming it's partially built but unverified.

2. We want exactly 100 founding members. DECISIONS.md specifies this cap, but I haven't verified it's enforced in code. I'm assuming we want to honor it and avoid accidental overages.

3. Founding member pricing is permanent. DECISIONS.md says "locked permanently," which I interpret as: once a user is flagged as a founding member, they stay at that price even if they cancel and resubscribe. Needs verification.

4. 14-day free trial auto-converts to paid. No opt-in required. User signs up, gets 14 days free, day 15 they're charged automatically. If they haven't chosen a tier, we charge for the tier they selected during signup.

5. Annual billing requires upfront payment. No installments, no prorated refunds. User pays $468 (Solo annual) or $948 (Pro annual) upfront and gets 12 months of access.

6. API costs are ~$0.07/user/month. This is the estimate from DECISIONS.md. Actual costs will vary based on usage patterns (regeneration rate, carousel frequency, photo analysis). I've flagged this as uncertain.

Biggest Uncertainties:

1. Stripe integration actually works end-to-end. This is the #1 uncertainty. We don't have documented proof that signup → trial → paid transition works. This should be verified this week.

2. Founding member pricing is correctly implemented in Stripe. Are the price IDs set up? Is the founding member flag correctly passed to Stripe? Does the price stick if they cancel and resubscribe? Unknown.

3. Annual billing is fully built. DECISIONS.md specifies the pricing, but I haven't seen evidence of the UI toggle or Stripe price ID configuration.

4. Trial-to-paid conversion is automated, not manual. Is there a cron job that runs every day and charges users on day 15? Or does it require Jason to manually click a button? Unknown.

5. Founding member acquisition will hit 100. The revenue projections assume we fill 100 spots over 60 days. If we only get 30 founding members, revenue drops to ~$1,500/month instead of $5K. This depends entirely on Jason's distribution channels.

10

Conclusion & Recommendation

Launch Readiness: CONDITIONAL GO

Stylify can launch after Meta approval (~March 5) IF AND ONLY IF the 7 blockers are resolved this week (by 2/28). The financial fundamentals are sound — the product has strong unit economics (96%+ margins), break-even is month 1, and payback is weeks 4-5. The constraint is not money; it's uncertainty about whether the billing system actually works.

This week's must-dos (2/24-2/28):

Verify Stripe integration works end-to-end (account creation → trial → paid charge)
Verify founding member pricing is correctly implemented and locked
Verify trial-to-paid conversion happens automatically on day 15
Implement annual billing (UI toggle + Stripe price IDs)
Test the full signup → payment flow as a real user
Document Stripe configuration (product/price IDs, webhooks, etc.)
Enforce the 100 founding member cap in code

Pre-launch (by March 5):

Upgrade Supabase to Pro ($25/mo) — target March 1
Document refund policy exceptions in ToS

Once these are done, Stylify is ready to accept founding members. The post-launch tasks (dunning emails, cancellation flow, retention automation, referral program) can ship in Month 1 without blocking the launch.

Financial Upside: At 100 founding members, we're at $4,900/month recurring revenue + $1,200/month annual prepays = $6,100/month gross revenue in month 3. Operating costs are <$200/month. This is a highly profitable business from day 1.