Case study 04 of 09

inRol

Student enrollment and registration

An established enrollment system for 6+ tenants, where I owned features and change requests, including Devanagari contracts and bus cards.

• Role: Feature owner
• Organisation: Pexus Tech
• Domain: EdTech · enrollment and registration
• Scope of involvement: Feature ownership (owned features, enhancements and change requests)
• Scale: 6+ tenants

In numbers

• 6+: tenants on inRol

Overview

inRol is a student enrollment system used by 6+ tenants for student registration and enrollment processes. It is an established, legacy production system that keeps evolving through feature enhancements, major change requests and tenant-specific requirements.

Product challenge

New business needs have to land in a system that institutions already rely on. Every enhancement has to fit existing data and workflows, and serve tenants whose requirements differ.

My role

Feature ownership. I did not rebuild inRol or own every part of it; my work was the features, enhancements and change requests below.

• Owned numerous features, enhancements and change requests.
• Worked on major product improvements while supporting the existing legacy system.
• Owned delivery of dynamic student contract generation, including support for Devanagari script.
• Worked on bus card generation.

Key features

• Dynamic student contracts: contracts generated dynamically for each student, with Devanagari support so they can be produced in the script used for Nepali. A localisation requirement, not just a formatting one.
• Bus card generation: bus cards produced within the system, an operational need handled alongside enrollment.
• Enhancements and change requests across the existing product.

Product thinking

• Localisation: generated documents must render Devanagari correctly, not only display it on screen.
• Operations: enrollment covers more than registration, so artefacts like bus cards belong in the same flow.
• Legacy constraints: changes have to coexist with existing data, workflows and tenants already in production.
• Tenant variation: requirements differ across 6+ tenants and have to be reconciled within one system.

Outcome

inRol gained dynamic student contract generation with Devanagari support and bus card generation, delivered into a live system used by 6+ tenants.

Skills demonstrated

Legacy product evolution · Change-request management · Localisation requirements · Tenant-specific requirements · Feature delivery