Allotix - Course & Elective Allocation SaaS

Allotix is a course and elective allocation platform for colleges and universities, built and run under my product studio PankoByte. Many institutions still allot electives with Google Forms, spreadsheets and first-come-first-served portals, which leads to data errors, uncontrolled edits and outcomes nobody can explain. Allotix replaces that with one guided workflow: import academic data, collect ranked preferences in a controlled window, run a capacity-aware allocation, publish results and export reports.

The product is live at allotix.com, is used by institutions running real allocation cycles, and is listed and verified on SaaS Browser. Pricing is pay-per-student-allocated through prepaid credits.

The same engine (ranked preferences, eligibility rules and capacity limits) handles any oversubscribed allocation an institution runs:

• NEP-2020 baskets: MDC, AEC, SEC, VAC and Minor (Vocational) pools mandated by the FYUGP
• Open electives: rank the electives, respect the seat matrix, publish a defensible result
• Minor & Honours: allot minor streams and honours tracks from an oversubscribed pool
• Specialisation & branch allotment on merit and preference
• Section & lab batches: split a cohort into sections or tutorial batches under real capacity limits
• On request: clubs, project guides, internship slots, hostel rooms and faculty workload

Admin Portal:

• Event lifecycle: every allocation event moves through five explicit phases (setup → preference collection → allocation → results → archive)
• Academic data management: add, edit, bulk import and export departments, courses (with department-wise and shared seat capacity) and students via CSV/Excel
• Submission tracking: monitor who has submitted and send reminder emails to pending students
• Allocation operations: start or reset allocation, track progress live, and filter outcomes (allocated, unallocated, no preference)
• Reports & analytics: preference-rank distribution, unallocated breakdown, course-wise fill, capacity utilisation and demand heatmaps, exportable for committees
• Communication: portal-open, acknowledgement, result, instructor and department report emails

Student Portal:

• Verified sign-up and login with institutional email
• Course catalogue with eligibility, prerequisites, credits, instructor and live seat capacity
• Drag-to-rank preference builder that requires every eligible course to be ranked
• Downloadable acknowledgement and result PDFs
• Result view with preference outcome and classmates in the allocated course

Allocation runs as a background job on the backend, with progress written back so the admin UI can poll it.

Ordering policy (chosen once per event and immutable afterwards):

• Merit: highest merit score first
• First-come-first-serve: earliest preference submission first
• Lucky draw: a Fisher–Yates shuffle backed by a cryptographic RNG

Seat assignment: each student, in policy order, is walked through their preferences by rank. A course can reserve seats per department (fixed capacity) and also expose a shared pool any eligible department can draw from. The first preference with a free seat wins and the rank achieved is recorded.

Copy
FOR student IN ORDER_BY_POLICY(students, policy) DO
    FOR pref IN SORT(student.preferences BY priority) DO
        course = courses[pref.courseId]
        IF NOT course.isActive THEN CONTINUE
        dept = course.capacityFor(student.department)
        IF dept.isShared AND course.sharedFilled < course.sharedCapacity THEN
            course.sharedFilled++ ; ALLOCATE(student, course, pref.priority) ; BREAK
        ELSE IF dept.filled < dept.capacity THEN
            dept.filled++ ; ALLOCATE(student, course, pref.priority) ; BREAK
        END IF
    END FOR
END FOR
SNAPSHOT_REPORT(courses, students)

Every outcome is traceable to a rule: the ordering policy, the preferences submitted, and the seat state at the moment of allotment. Unallocated students are surfaced with a reason before results are published, so the academic office can intervene on purpose.

Frontend (Allotix-UI):

• React 19 + TypeScript + Vite, React Router
• Tailwind CSS + Radix UI components, Motion animations
• React Hook Form + Zod for validated admin forms
• Recharts for allocation analytics, @react-pdf/renderer for acknowledgement and result PDFs, xlsx for exports
• Firebase Web SDK for student authentication

Backend (Allotix-API):

• NestJS + TypeScript, modules organised by capability (admin/*, student/*, mail/*), Swagger docs
• Firebase Admin SDK with Cloud Firestore, all data scoped under events/{eventId}/...
• Google Cloud Run (Docker) for the API and Cloud Tasks for background allocation and email jobs
• CSV/Excel import with csv-parse and xlsx, Handlebars email templates sent through the Emailit API

Marketing site: a separate prerendered React + Vite site with per-solution landing pages for SEO.

Allocation decides who gets a seat, so the system is built to survive institutional procurement and IT review:

• Role-separated portals: admin routes use JWT, student routes verify Firebase ID tokens; a student session can never reach an admin route
• Backend-enforced phase guards: allocation, publishing and reporting are gated at the API layer, not just hidden in the UI
• Event-scoped isolation: backend-verified event membership is the authoritative access check for a student's data
• No direct database access: Firestore security rules deny all client access; data only flows through the backend
• Authenticated service boundaries: internal task endpoints are protected by Cloud Tasks OIDC
• Data stays in India: institutional and student records are stored and processed in Indian data centres

• Website: allotix.com
• Solutions: allotix.com/solutions
• Security: allotix.com/security
• Verified listing: SaaS Browser