Loading Abhiram Reddy Palle

Abhi/ 26
Your time on this site
→All workCase study 01 / 04

Product · Access & permissions

Infin8 Access

Permission slips, minus the paper.

Type
Product · Access & permissions
Role
[Add role]
Year
[Add year]
Status
Shipped

(01)The problem

Paper permission workflows are slow and opaque. A request has to physically travel from desk to desk, it can stall anywhere, it's easy to lose, and nobody can see where it's stuck. When it's finally approved, the only proof is a sheet of paper.

(02)The idea

One flow instead of a paper trail. A request moves Student → HOD → Coordinator, every role only sees what it can act on, admins see the whole picture, and the end result is a QR code anyone can verify on the spot.

(03)The build

The frontend is React and TypeScript on Vite, styled with Tailwind. The API is Hono running on Cloudflare Workers, backed by Cloudflare D1 — SQL at the edge, no server to babysit.

Identity travels in JWTs signed and verified with the Web Crypto API. Four roles — Student, HOD, Coordinator and Admin — each get their own workflow, with admin dashboards on top.

Student data arrives as Excel sheets, so the importer is deterministic, idempotent and duplicate-safe: it synchronises structured student records into D1 without creating duplicates, however many times it runs.

The approval chain
  1. 01→StudentRaises the request
  2. 02→HODReviews it
  3. 03→CoordinatorFinal review
  4. 04■CompletionA verifiable QR is issued

04 roles, each with its own workflow

  • R01StudentRaises requests, tracks them, carries the QR.
  • R02HODReviews requests for their department.
  • R03CoordinatorGives the final review.
  • R04AdminDashboards, imports and oversight.
Frontend
React/TypeScript/Vite/Tailwind CSS
Backend
Cloudflare Workers/Hono
Data
Cloudflare D1/SQL
Auth & verification
JWT/Web Crypto API/QR

(04)The hard part

  1. 01

    Roles are the whole product

    An HOD shouldn't touch the coordinator's stage, and a student shouldn't approve anything. Every transition is authorised server-side, not just checked at login.

  2. 02

    Import it twice, get the same database

    Excel is messy and people re-upload files. The importer is deterministic and idempotent, so running it again changes nothing — and duplicates never get in.

  3. 03

    State that can't slip backwards

    Each request is a small state machine. Every move between stages has to be valid, deliberate and visible to the people waiting on it.

  4. 04

    Designing for the edge

    Workers and D1 remove the server entirely — great, until you have to think in short-lived requests against a serverless SQL database.

(05)The result

Real users on a real campus: requests flow through the approval chain to QR-verified completion, with role-specific views, admin dashboards and bulk student import.

[ADD NUMBERS — users, requests, departments (only real ones)]

Live[Add link]Code[Add link]Video[Add link]

(06)What's next

First versions are rarely the final versions. This one won't be either.

[Add what you'd improve next]

(07)Under the hood

Request → approvalIllustration
QR identity · role-based approval200+ active club members

The same picture the film runs — an illustration of how Infin8 Access thinks, not a screenshot.

(08)Screens

Raising a requestScreen 01
An approval stageScreen 02
QR verificationScreen 03
Next — 02 / 18Developer tool · SecuritySecret Leak Detector→Catches the key before it's in your git history.