Free forever: 5 resume reviews + 10 AI actions every month. Claim your free spot →
ReachRole

Full Stack project

Build a subscription lifecycle with mock billing

Plan changes, a webhook handler, and billing history — the idempotency and edge-case handling here is what real billing code is actually graded on.

10-13 hoursEstimated time
AdvancedDifficulty
5Graded criteria
RepoWhat you submit

The brief

Build a subscription flow: plan selection, a mock "charge" endpoint you control (with a way to force it to fail, simulating a real payment provider without needing one), a webhook-style handler that updates subscription status when a charge event arrives, and a billing history page. Support upgrade, downgrade, and cancel, and decide (and document) when each takes effect.

Suggested stack

React or similar frontend Node.js or any backend framework PostgreSQL or SQLite

What you hand in

  • A public GitHub repository with the running app and a README
  • The README documents the subscription state machine and how upgrade/downgrade/cancel each behave
  • A short note on how webhook idempotency is handled

Grading happens against the rubric below, so read it before you start — not after.

How this is graded

Published in advance and weighted out of 100. Nothing here is a surprise.

Subscription lifecycle state machine correctness 30 pts

Every transition (trial to active, active to cancelled, plan change) leaves the subscription in a consistent, correctly-labeled state, with no state the UI can't explain.

Idempotent webhook handling 25 pts

Receiving the same charge event twice does not double-apply it (no double credit, no double status flip) — there's an idempotency key or equivalent check.

Plan change edge cases 20 pts

Upgrading mid-cycle, downgrading, and cancel-then-resubscribe are all handled deliberately and documented, not left to whatever the code happens to do.

UI reflects real state 15 pts

The billing history and current plan shown in the UI always match the actual server-side subscription state, including after a simulated failed charge.

Finish 10 pts

No console errors or crashes, no broken layout, no leftover placeholder text or commented-out code.

Why this project is worth your weekend

  • Billing bugs cost real money and touch nearly every payments-adjacent job, making this one of the highest-signal full-stack projects available.
  • Idempotent webhook handling is a concept that shows up constantly in real payment integrations (Stripe, Razorpay, etc.) and is rarely taught in tutorials.
  • This forces genuine edge-case thinking past basic CRUD, which is exactly where junior-to-mid full-stack candidates are differentiated.

Where people lose points

  • Processing the same webhook event twice and double-crediting or double-flipping subscription status because there's no idempotency check.
  • Leaving the UI showing "payment successful" when a charge actually failed after the initial optimistic update, with no reconciliation.
  • Applying a downgrade immediately instead of at the end of the paid period, without stating which behavior was chosen and why.

Other Full Stack projects

Two or three of these turn an empty resume into a portfolio.

Back to the roadmap

Built it? Get it scored against this rubric.

Submit your work and get a score on every criterion above, written feedback, and three resume bullets you can use straight away.

Submit for grading Free to start. Grading uses one AI action.