Professional Project
OstimGPT
A locally hosted Retrieval-Augmented Generation chatbot answering questions from university sources.
Professional Project
Student Application Management System
SAMS is a digital student application platform supporting applicant profiles, internal review processes, application status management, reporting and locally hosted AI-backed language configuration. Within the development team I built profile interfaces, an internal notes panel for reviewers, form-to-submission synchronisation, an application status API endpoint and a configurable reporting dashboard.
Jump to section
Overview
The Student Application Management System is a digital platform for handling student applications end to end: applicants build a profile and submit an application, and staff review those applications, record internal notes, move them through status changes and report on the result.
I contributed to this platform as a member of the university’s development team. My work concentrated on the interfaces applicants and reviewers actually use, on keeping submitted data consistent with the forms that produced it, and on the reporting and status surfaces built on top.
Context
Student applications are a recurring, high-volume administrative process with two distinct audiences: applicants, who use the system once or twice and need it to be self-explanatory, and internal reviewers, who use it constantly and need it to be efficient.
A platform serving both audiences has to be designed for both. Much of my work sat on the reviewer side, where small friction is repeated hundreds of times.
Problem
An application process handled across disconnected forms, spreadsheets and email loses context. Reviewers cannot see why a decision was made, applicants cannot see where their application stands, and reporting means reconstructing the picture by hand.
- Applicants and internal reviewers needed different interfaces over the same underlying application.
- Reviewer context — notes, review state — had to live with the application rather than outside it.
- Submitted data had to stay consistent with the form fields that produced it, even as forms changed.
- Application status had to be available to other parts of the system programmatically.
- Reporting needed to be configurable rather than a fixed set of predefined views.
My Role
My Role
I developed the Profile Page user interface and the Applicant Profile Page, and built an Internal Notes Panel for reviewers. I implemented automatic synchronisation between form fields and submissions, and extended the submission models with review-related fields. I developed an application status API endpoint and created a configurable reporting dashboard. I also helped migrate the platform’s language configuration to a separate service backed by locally hosted models.
Team Context
Team Context
This is a university platform built and maintained by the software development team in the Digital Transformation Coordination Office. I was a contributor on that team, not the owner of the platform. The features described here are the ones I personally developed; the platform as a whole — its architecture, its other modules and its operation — is the team’s shared work, developed in sprints with collaborative code review.
Responsibilities
Applicant and reviewer interfaces
- Developed the Profile Page user interface.
- Developed the Applicant Profile Page.
- Built an Internal Notes Panel for reviewers.
Data consistency and models
- Implemented automatic synchronisation between form fields and submissions.
- Extended submission models with review-related fields.
APIs and reporting
- Developed an application status API endpoint.
- Created a configurable reporting dashboard.
AI-backed configuration
- Helped migrate language configuration to a separate service using locally hosted models.
Technical Approach
The work followed the application’s own lifecycle: give the applicant a coherent profile, give the reviewer the context needed to decide, keep the underlying data consistent as both sides change it, then expose status and reporting on top of that foundation.
- Build the Profile Page and Applicant Profile Page so an application is viewable as one coherent record rather than a set of form responses.
- Add an Internal Notes Panel so reviewer reasoning is captured against the application itself instead of in email.
- Extend the submission models with review-related fields, so review state has a proper home in the data model.
- Synchronise form fields and submissions automatically, so a change to a form does not silently desynchronise the data it collects.
- Expose an application status API endpoint so other parts of the system can read status without reaching into the platform’s internals.
- Build a configurable reporting dashboard so staff can shape a report rather than request a new one.
- Move language configuration into a separate service backed by locally hosted models.
Architecture
An applicant creates a profile and submits an application. The submission is stored against models that carry both application data and review-related fields, kept in step with the form definition by automatic synchronisation. Reviewers work through the applicant profile page and an internal notes panel. Application status is exposed through an API endpoint, and a configurable reporting dashboard reads across submissions. Language configuration is handled by a separate service backed by locally hosted models.
- Applicant: creates a profile and submits an application through the profile interface.
- Synchronisation: form fields and submission records are kept aligned automatically.
- Storage: submissions are held in models extended with review-related fields.
- Review: staff open the applicant profile page and record reasoning in the internal notes panel.
- Status: application status is exposed through a dedicated API endpoint for other consumers.
- Reporting: a configurable dashboard reads across submissions to produce reports.
- Language: configuration is served by a separate service backed by locally hosted models.
Features
Applicant profile page
An application viewed as a single coherent record rather than a set of form answers.
Internal notes panel
Reviewer reasoning captured against the application itself, where the next reviewer will find it.
Form and submission synchronisation
Form fields and submitted data stay aligned automatically as forms change.
Review-aware data model
Submission models extended with review-related fields, giving review state a real home.
Application status API
A dedicated endpoint so other parts of the system can read status directly.
Configurable reporting dashboard
Staff shape the report they need instead of requesting a new fixed view.
Challenges
Forms change over time, and submitted data captured under an older form definition drifts out of step with the current one.
I implemented automatic synchronisation between form fields and submissions so the relationship is maintained by the system rather than by whoever remembers to update it.
Review state — notes, decisions, context — had nowhere structured to live, which pushes it into email and side channels where it stops being part of the record.
I extended the submission models with review-related fields and built the Internal Notes Panel on top, so reviewer context is stored with the application it belongs to.
Fixed reports create a queue: every new question becomes a development request.
I built the reporting dashboard to be configurable, so staff can answer new questions without waiting for a code change.
Decisions and Tradeoffs
| Decision | Alternative considered | Why |
|---|---|---|
| Extend the existing submission models with review-related fields. | Keep review state in a separate store alongside submissions. | Keeping review state with the submission means a single record tells the whole story and cannot fall out of sync. It does make the submission model larger, which is the accepted cost. |
| Make reporting configurable rather than shipping fixed reports. | A set of predefined report views. | Configurable reporting is more work upfront but removes a recurring dependency on developers for every new question. Fixed reports are faster to build and slower to live with. |
| Move language configuration into a separate service backed by locally hosted models. | Keep language configuration inside the main application. | Separating it keeps model-backed behaviour out of the application’s core and lets it be changed independently. It adds a service boundary to operate, which was the trade accepted. |
Result
Applicants have a profile-based view of their application, and reviewers have an applicant profile page with an internal notes panel that keeps their reasoning attached to the application record.
Submitted data stays aligned with the forms that produced it through automatic synchronisation, and review state has a defined place in the submission model.
Application status is available through a dedicated API endpoint, and staff can shape reports themselves through the configurable reporting dashboard.
Lessons Learned
- Interfaces used every day and interfaces used once deserve different design attention. Reviewer friction compounds in a way applicant friction does not.
- Where state lives determines whether it survives. Giving review notes a real home in the data model is what stops them ending up in email.
- Synchronisation between a form definition and the data it collects is a correctness feature, not a convenience one — the failure is silent, which makes it worse.
- Configurability is worth its cost when the alternative is a permanent queue of report requests.
- Working inside an established team codebase means reading far more code than writing it, and code review is where most of the learning happens.
Technology Stack
Backend
Frontend
AI and retrieval
Practices
Screenshots
Screenshots to be added
Let’s discuss your project
Have a software, AI, RAG, or web application project in mind? Let’s discuss what you need and determine the right technical approach.