Step 1 of 6
Define billing and usage data model
Create persistent tables to store usage events, rates, and invoices.
The app uses a PostgreSQL database accessed via an ORM (e.g., Prisma or Sequelize). Existing user table is `users(id, ...)`.
Write a database migration that adds three new tables: 1. `usage_events` with columns: `id PK`, `user_id FK -> users.id`, `event_type VARCHAR`, `quantity INT`, `recorded_at TIMESTAMP`. 2. `rate_plans` with columns: `id PK`, `name VARCHAR`, `unit_price_cents INT`, `tier_start INT`, `tier_end INT` (allow null for unlimited). 3. `invoices` with columns: `id PK`, `user_id FK`, `period_start DATE`, `period_end DATE`, `total_cents INT`, `status VARCHAR` (pending/paid), `created_at TIMESTAMP`. Make the migration idempotent, add foreign key constraints, and generate the corresponding ORM models. Finally, run the migration against a local dev DB and verify tables exist.
Expected after this step
Three new tables exist in the local DB with correct columns, foreign keys, and ORM models are generated.
Should not happen
- ✕AI returns placeholder SQL or ORM definitions without executing migrations.
- ✕Usage middleware logs to console instead of inserting rows.
- ✕Billing service uses hard‑coded totals or skips DB transactions.
- ✕Stripe integration uses mock objects or omits webhook verification.
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !AI returns placeholder SQL or ORM definitions without executing migrations.
- !Usage middleware logs to console instead of inserting rows.
- !Billing service uses hard‑coded totals or skips DB transactions.
- !Stripe integration uses mock objects or omits webhook verification.
- !Admin endpoints return static JSON instead of querying the DB.
- !E2E test relies on mocked Stripe SDK or fake DB fixtures.
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
The migration did not create real tables or used placeholders. Re‑run the migration with concrete SQL/ORM code that actually creates `usage_events`, `rate_plans`, and `invoices` with the specified columns and foreign keys, and verify by querying the DB.