Skip to content
DheesoftDheesoft home
Back to work
Case study · Government polytechnic ERP

Government polytechnic — bilingual ID card ERP

A bilingual ID card ERP for a government polytechnic — print-grade CR80 PDFs, public QR verification and a SaaS-ready core.

  • Live
  • Since May 2026
  • 8K+ students
Visit live portal
Polytechnic portal login hero

By the numbers

Students enrolled
8K+
Departments
12
Entity schemas
9
Languages
2

01The problem

A government polytechnic institute with roughly eight thousand students across twelve departments was running admissions through a Google Form and producing student ID cards offline. Cards had to be bilingual (Bengali primary, English fallback), pixel-correct for an 87×54mm CR80 dye-sublimation printer, and trustworthy enough that anyone could verify a card on the street. None of that fit a Google Form export — and none of it fit a generic SIS either. The portal had to handle authority staff issuing cards in bulk, students self-registering, lost-card reprint requests, and a public verify URL behind a QR code on every card.

02What we built

  1. 01

    Print-grade bilingual ID card pipeline — 87×54mm CR80 cards laid out for a HiTi CS-2 dye-sublimation printer, with Hind Siliguri and Plus Jakarta Sans embedded so Bengali and English render correctly through every step (browser preview, PDF, ZIP, printer driver).

  2. 02

    ID card design customization — accent colour, landscape or portrait orientation, institute information, department signature management, and bulk export so authority staff can tune the card without engineering touching it.

  3. 03

    A one-shot importer that turns the legacy Google Form CSV export into validated student records — column mapping, Bengali name normalisation, per-row error rows reported back, and duplicate roll/registration protection so the migration runs cleanly the first time.

  4. 04

    A lost-card / reprint request flow — students raise a request from their account, authority staff review in a queue, on approval the card version bumps and a fresh PDF can be issued without touching any other student data.

  5. 05

    An approval state machine on a single approvalRequests table — self-registered students submit a profile, authority bulk-approves, profile updates queue as diffs, and cardVersion increments on every accepted edit so reissued cards are auditable.

  6. 06

    A public QR-coded verify route at /verify/[id] — every printed card carries a QR encoding the student record, so anyone with a phone can scan a card and confirm the holder against the live database without an account.

  7. 07

    Single-tenant flag on a multi-tenant core — the same Drizzle schema runs as one institute today, but every table carries a tenantId and every query scopes through a single helper, so the platform lifts to a SaaS polytechnic ERP without a schema migration.

03Stack

Public + student

  • Next.js 15
  • React 19
  • Tailwind 4
  • next-intl
  • Hind Siliguri
  • Plus Jakarta Sans
  • RTK Query
  • shadcn/ui

Authority + admin

  • Better Auth
  • 5-role RBAC
  • Invitation flow
  • TanStack Table
  • react-hook-form
  • sharp
  • html2canvas
  • JSZip

Data + print pipeline

  • NestJS 10
  • Drizzle ORM
  • PostgreSQL
  • Puppeteer
  • 9 entity schemas
  • Single-tenant flag
  • Multer + sharp
  • Public QR verify

04Screenshots

05The hard part

The hardest part wasn't the schema — it was making a Bengali ID card survive every transition from screen to print without breaking. CR80 dye-sublimation printers are unforgiving: 87×54mm of physical paper, sub-pixel rendering, and a Bengali script with conjunct ligatures that most webfonts mangle. We had to embed Hind Siliguri for Bengali and Plus Jakarta Sans for English directly into the PDF, validate against the HiTi CS-2 driver, and design both landscape and portrait variants so the same student record produces a correct card in either orientation. Print-grade typography on the web is a different problem than print-grade typography in print, and Bengali makes both harder than English.

The second hard part was the bridge between the old world and the new one. The polytechnic had been running admissions through a Google Form for years, so the migration had to import a real CSV into a real database — not a hand-typed re-entry. We built a one-shot importer that maps Google Form column headers to the Drizzle schema, normalises Bengali names, validates departments and blood groups, surfaces every bad row, and refuses to import duplicate roll or registration numbers. Once that ran, the institute could leave the Google Form behind and trust the portal as the system of record — and the public QR verify route closed the loop on physical card trust.

Your move

Want one built around your operation?

We take on a small number of custom engagements per year. If this looks close to a problem you have, tell us about it.