2025 · SHIPPED · MEMORY

GUB Portal

Nobody should have to sit refreshing a page at midnight

Next.js
TypeScript
Firestore
Cron
PWA

GUB Portal is a faster front end for the Green University of Bangladesh student portal, built around one thing the official site does not do: registering courses the moment pre-registration opens, without a student sitting on the page refreshing.

Everything else — routine, results, billing, profile — is a faster, mobile-first read of the same portal data. It is a personal tool that acts on a student's own session, is not affiliated with or endorsed by the university, and is marked noindex.

Problem

Course pre-registration at my university opens at a moment, and seats go immediately. The official portal offers no way to queue a plan, so the actual mechanism is a student refreshing a page for an hour hoping to be fast enough.

Question

Can a personal tool act on a student's own portal session to satisfy a saved plan — and can it keep working when their laptop is closed, without becoming something that should not exist?

Approach

Two engines chase the same saved plan. A browser engine runs while the page is open; a server engine runs when it is not. Both share one queue builder, so a course already registered is skipped by either, and a per-student Firestore lease stops the two from submitting the same course at once. It is scoped and labelled as a personal tool, is not affiliated with the university, and is marked noindex so it never appears in search.

System

Open any stage to see what it does.

PLAN — Courses in priority order, each with preferred sections. Saved once, ahead of time.

RUN QUEUE — buildRunQueue — one shared function producing the work list, so both engines agree on what is left to do.

BROWSER ENGINE — Runs while the page is open. Retries roughly every 15 seconds, up to 40 passes.

SERVER ENGINE — /api/cron/auto-run — runs when the browser is closed or offline, retrying repeatedly within each invocation. Only for students who are explicitly armed.

FIRESTORE LEASE — A per-student lease so the two engines never submit the same course at the same time.

PORTAL READ — Routine, results, billing and profile — a faster, mobile-first read of the same portal data.

Demo

Save a registration plan, arm the server engine, close the laptop. Routine, results, billing and profile are available as a faster mobile-first read of the portal.

Result

Two independent engines satisfy one saved plan without double-submitting, coordinated by a per-student Firestore lease.
The browser engine retries every ~15 seconds for up to 40 passes; the server engine retries within each cron invocation.
Marked noindex and documented as an unaffiliated personal tool, with the security trade-off of storing a portal session written down explicitly in OFFLINE_AUTO_RUN.md.

Lesson

The hardest part was not the automation, it was deciding how much of it to build. Storing someone's portal session so a server can act while they sleep is a real trade-off, and the right response was to document it plainly and make arming an explicit, opt-in act rather than to quietly default it on.

Source

GUB Portal — repository ↗

Connected

hdgame.me — Both are WEB and SYSTEMS and CLOUD work, and both are built with Next.js, TypeScript.
TeleFlow — Both are WEB and SYSTEMS and CLOUD work, and both are built with Next.js, TypeScript.
Bazario — Both are WEB and SYSTEMS work, and both are built with Next.js, TypeScript, PWA.
GreenGuardian — Both are WEB and CLOUD work, and both are built with Next.js 16, TypeScript.