Sessions and logout-all
Sign in on many devices. One action revokes every session.
Verification platform
Verifier App for UzSU
A production membership platform that connects subscription choices, member records, digital QR passes, public verification, and administration in one workflow.
The problem
UzSU needed membership status that could be checked immediately while keeping subscription, profile, and verification data structured enough for daily administration.
Built with
A Angular angular.dev N NestJS nestjs.com TS TypeScript typescriptlang.org P Prisma prisma.io Pg PostgreSQL postgresql.org S Stripe stripe.com
- Client
- Uzbekistan's Students Union
- Year
- 2025
- Role
- Architecture, full-stack development, and payments workflow
- Status
- Live
Screens
Desktop and mobile
The membership platform on desktop and mobile: plans, member records, QR passes and public verification in one workflow.
Valid pass
A checked pass resolves to a status, a member type, a region and an expiry date.
Member cabinet
A member's own record: membership status, identifiers, and the profile the pass is issued against.
Pass and billing
The QR pass, the account and billing controls beside it, and the partner offers the paid tier unlocks.
Membership plans
Region decides which plans a student is offered. Standard is free; Premium is the Stripe-backed paid tier.
Admin roster
Every member with status, tier, region and billing state, filterable across all three.
Branch application
The public form that routes a volunteer to a branch, then to a team and a position.
Application review
Submissions carry a reference and a delivery state, filterable by branch and team.
System
Features
QR pass grace period
The pass keeps working while a payment is past due.
Blocked pass reveals nothing
No name, email, photo or expiry. Only valid or not.
Atomic password setup and reset
72 hours to set up, 30 minutes to reset, one transaction.
Admin sessions and link issuance
12-hour admin sessions. Admins issue links, never set passwords.
In-app notification centre
Ten account, billing and support events, tracked per member.
Partner offers behind the paid tier
Premium members see the partner discounts their membership unlocks.
Branch volunteer applications
A public form routes a volunteer to a branch, team and position, with a CV attached.
Application review console
Submissions carry a reference and a delivery state, filterable by branch and team.
Decisions and tradeoffs
Problems we hit
History rows shadowing active membership
Problem
A member can accumulate multiple membership rows: a historical cancelled record alongside a current active one.
Our solution
Derive the status, never read it
A canonical projection derives the authoritative status, preventing stale or cancelled rows from overriding a valid paid entitlement and vice versa.
Concurrent password links causing conflicts
Problem
Multiple simultaneous forgot-password requests could deliver competing active links to the same member.
Our solution
One lease, one idempotency key
One short-lived database lease per member and purpose, with the token ID as the email provider's idempotency key, so concurrent requests produce only one link and provider retries do not re-deliver it.
Declared file type is unverifiable
Problem
Browser-declared MIME types and original filenames cannot confirm that an uploaded file is genuinely an image.
Our solution
Decode the bytes, re-encode the result
The server decodes the raw bytes to confirm the format, rejects multi-frame or oversized files, and re-encodes the result as a clean JPEG.
Reset secrets exposed in browser history
Problem
Password setup and reset secrets passed in query strings appear in server logs and browser history.
Our solution
Move the secret to the URL fragment
Fragments never reach the server. The browser retains the fragment only in memory during a temporary validation failure, to allow a safe retry.
Decisions we made
Membership is data, not a generated image
Decision
The central decision was to model membership as data, not as a generated image.
Why we made it
The QR pass is only a portable pointer into the current record. Expiry, plan, and active status remain server-controlled, so a previously issued pass cannot become a permanent source of truth by itself.
The public surface stays narrow
Decision
The second decision was to keep the public verification surface separate from the richer member cabinet and administration views.
Why we made it
Public verification should reveal only the result needed for the interaction; profile, billing, and internal management information stay behind authenticated access.
Signup and operations share one plan definition
Decision
The application also connects public acquisition and internal operations.
Why we made it
The same plan definitions shown during signup feed the membership and subscription workflow, rather than creating a disconnected marketing page that staff later reconcile manually.
Next
Contact
Let's talk.
For professional opportunities, collaborations, or selected freelance work.
Open to conversations Frankfurt, Germany Europe/Berlin
GitHub penguindevteam@gmail.com