Settings/Billing Page
Build a real settings area: profile edits that persist, password change, plan display, and danger zone.
The route
6 steps to Done
- 01
Define settings sections
Inventory every setting and its backing field before building.
Preview prompt + verify gate ▾ Hide ▴
Define the settings spec. List the sections - Profile (name, email), Security (password change), Preferences (2-3 real toggles/selects used by the app), Plan/Billing (current plan display, upgrade CTA), Danger Zone (delete account) - and for each control: the backing database field, validation rules, and the endpoint that persists it. Cut any control with no real backing field.
- ✓ Every control names its database field
- ✓ Validation rules are defined
- ✓ No decorative controls remain
- 02
Build layout and profile section
Stand up the settings shell with the first real persisting section.
Preview prompt + verify gate ▾ Hide ▴
Build the settings page with section navigation and implement Profile. Requirements: name and email fields prefilled from the user record; validation (email format, name required); Save with loading state; persistence via the backend; success toast and visible errors; changed-email uniqueness handled; refresh and re-login show the new values. Protect the page behind auth.
- ✓ Prefill comes from the real user record
- ✓ Save persists across refresh and re-login
- ✓ Duplicate email fails with a visible error
- 03
Implement password change
Security controls must verify identity and truly rotate the credential.
Preview prompt + verify gate ▾ Hide ▴
Implement password change. Requirements: current password, new password, confirm fields; backend verifies the current password against the stored hash before updating; new password validated (min length shown in UI) and hashed; wrong current password shows a specific visible error; on success, confirm the new password works and the old one fails on next login.
- ✓ Wrong current password is rejected visibly
- ✓ New password works on next login
- ✓ Old password stops working
- 04
Implement preferences
Toggles must persist and actually affect the app.
Preview prompt + verify gate ▾ Hide ▴
Implement the Preferences section. Requirements: 2-3 real preferences (e.g. email notifications toggle, theme or default view select) persisted to the user record on change (auto-save or Save button - pick one and show state); values restore on reload; at least one preference visibly affects app behavior, demonstrated before/after.
- ✓ Toggle state survives refresh
- ✓ One preference demonstrably changes app behavior
- ✓ Save state (saving/saved) is visible
- 05
Add plan display and danger zone
Close the account loop: show the plan and make deletion real.
Preview prompt + verify gate ▾ Hide ▴
Implement Plan and Danger Zone. Requirements: show the user's current plan with feature summary and an Upgrade CTA (linking to billing/checkout or a coming-soon dialog); Danger Zone with Delete Account requiring typed confirmation (e.g. type DELETE); deletion removes/deactivates the account server-side, ends the session, redirects to the landing page, and blocks subsequent login with a clear message.
- ✓ Current plan reflects the stored value
- ✓ Delete requires typed confirmation
- ✓ Deleted account cannot log back in
- 06
Settings QA pass
Verify every control persists and every risk path is safe.
Preview prompt + verify gate ▾ Hide ▴
Run settings QA and report PASS/FAIL with evidence: each profile field persists across re-login; duplicate email blocked; password rotation verified both directions; every preference survives refresh; upgrade CTA works; delete flow blocks re-login; all forms validated; mobile layout at 375px. Fix all failures and re-run.
- ✓ Re-login persistence checked per field
- ✓ Password rotation double-checked
- ✓ Deletion verified with a blocked login
- ✓ All failures fixed