New Billing System — Launch Sprint
The April 20 launch was blocked by three confirmed bugs: expiry date miscalculation, late-firing cron charges, and early-firing test charges. This plan uses a 1 real day = 1 week accelerated test environment — all real billing formulas intact, just 7× faster — with all accounts on an April 27 start date so every charge fires on the same timeline.
Why the April 20 Launch Was Blocked
System used calendar months instead of 28-day billing cycles, causing expiry dates to be off by days to weeks.
Cron job timed out on large staging dataset before processing all accounts. Fix: reduce staging data volume.
Accelerated test cycle (1/3/6 days) was applied to cancelled accounts, causing premature charges in staging.
- Set test environment to 1 real day = 7 days (1 week) — preserves all real billing formulas, just 7x faster
- Confirm reduced staging dataset is in place (cron fix)
- Create all 8 test accounts with Start Date: April 27, 2026
- Verify C1 charges fire correctly and at the exact plan price (no gross/refund pattern)
- All programs start today (Apr 27 start date)
- C2 should fire 3 real days after start (Apr 27 + 21 days = May 18 in real time → 3 real days in test)
- Confirm C2 fires on Start Date + 21 days for all plan types
- Confirm cancelled accounts still show C2 firing (commitment lock-in)
- 3-Month cancelled accounts: C2 (Day 3) and C3 (Day 7) both fire on schedule
- 6-Month cancelled accounts: C2 through C6 all fire on schedule (C2 Day 3, C3 Day 7, C4 Day 11, C5 Day 15, C6 Day 19)
- Monthly cancelled accounts: no charges after cancellation date
- Each charge interval = 4 real days (28 billing days ÷ 7)
- Expiry date shown = Last Charge + 35 days for all plan types
- 3-Month expiry fires ~Day 12 (C3 + 35 days = 5 real days after C3)
- 6-Month expiry fires ~Day 24 (C6 + 35 days = 5 real days after C6)
- Account access remains active until expiry date
- "Next Week" meals blocked in final 7 days (Final Week rule)
- Account deactivates on expiry date
Test Account Matrix
The dev team should create these 8 accounts at the start of Week 1 to cover all critical billing scenarios.
| Account Name | Plan | Test Purpose |
|---|---|---|
| Test Monthly — Cancel before C2 | Monthly | Verify no further charges after cancellation |
| Test Monthly — Ongoing | Monthly | Verify C2, C3 fire correctly every 28 days |
| Test 3-Month — Cancel after C1 | 3-Month | Verify C2 and C3 still fire (commitment lock-in) |
| Test 3-Month — Cancel after C2 | 3-Month | Verify C3 still fires |
| Test 3-Month — Ongoing | 3-Month | Verify auto-renew into new 3-Month commitment |
| Test 6-Month — Cancel after C1 | 6-Month | Verify C2–C6 all still fire |
| Test 6-Month — Cancel mid-commitment (after C3) | 6-Month | Verify C4–C6 still fire |
| Test 6-Month — Ongoing | 6-Month | Verify auto-renew into new 6-Month commitment |
- Dev team addresses all bugs found in Week 1
- Review cancellation modal: must show plan type, charges remaining, exact expiry date
- Confirm commitment language is clear and accurate for all 3 plan types
- Re-run all critical test scenarios after fixes
- Cron job timing: confirm no late-firing charges with reduced dataset
- Expiry date accuracy: re-verify on at least 2 accounts per plan type
- Auto-renew: confirm new commitment starts correctly for ongoing accounts
- New customer signup → start date selection → meal preview access
- C2 fires → C3 fires → commitment completes
- Customer cancels → sees correct commitment language
- Account enters Final Week → Next Week meals blocked
- Account expires on correct date
- Non-technical walkthrough of cancellation flow by customer support
- Review all 14 go/no-go checklist items
- All critical items must be green
- If any critical item is red: extend to May 13 — do not launch
- If all green: launch on May 9
Go / No-Go Checklist
All critical items must be checked before launch on May 6.
Key Risks & Mitigations
The staging fix (reduce dataset) only addresses staging. Confirm with the dev team that the cron has been optimized for production-scale growth, or that a queue/batch approach has been implemented.
The test environment uses 1 real day = 7 days (1 week) acceleration. This preserves all real billing formulas — Start Date + 21 days for C2, then every 28 days — just compressed 7x. All formulas run exactly as they would in production.
Have a non-technical team member (e.g., customer support) walk through the cancellation flow and confirm the language is clear before launch.
If a critical bug is found after April 30, a one-week extension to May 13 is preferable to launching with a known issue. Customer trust is the priority.
Questions for the Next Dev Team Meeting
- 1
Has the cron job been optimized for production-scale data, or only reduced for staging? What is the plan as the customer base grows past a few hundred active accounts?
- 2
Is the gross-charge-then-refund pattern at signup intentional in the test environment, or will production charge the exact plan price directly?
- 3
Has the new cancellation flow UI been built? If so, can we review it before the regression test (Day 10)?
- 4
Are there any other features tied to this launch that haven't been discussed — new onboarding flow, pricing page, customer-facing cancellation portal?
- 5
What is the rollback plan if a critical bug is discovered after launch?
Before launch, consider sending a brief note to your existing Premium / grandfathered customers clarifying that their billing is unchanged and the new plans only apply to new signups. This prevents confusion and preempts support tickets on launch day.