Back to all work
Case study 02 Final Year Project

Swinburne Campus App

A mobile-first campus app built from what students actually asked for — 360° navigation at its core, with an AI assistant that knows its limits.

ClientSwinburne University of Technology Sarawak
Year2025–2026
RoleFull-stack — navigation, AI assistant, settings, security testing
TypeTeam project · deployed PWA

The problem

Swinburne's Sarawak campus has expanded fast — new buildings, renovated spaces, more faculties. Parents arrive for orientation days, school groups visit, and a fresh intake of students lands every semester. The problem is the same for all of them: people get lost.

Not vaguely lost — specifically lost. Standing in front of a building trying to figure out which room is on which floor, which hall a lecture is in, where the nearest admin office hides. The university's existing digital resources weren't built for navigation.

Evidence first, assumptions never:

Before building anything, we surveyed students: what do you struggle with most on campus, and what would you want in an app that doesn't exist yet? Navigation came back as the #1 problem — followed by campus events, funding information, and Canvas/IT support. Every module in the final product traces directly back to a survey response.

What I built

360° campus navigation — the core feature

  • Pick any starting point and any destination — a lecture hall, room number, office, or facility — and get a guided path through campus.
  • Built as the entry point of the app, not an afterthought buried in a tab bar.
  • Covers the survey's real use cases: new students finding rooms, parents and visitors on open days, school groups on campus tours.

AI campus assistant

  • Handles the queries students actually send staff: eduroam/Wi-Fi setup, Canvas login issues, fee clarification, visa support contacts, navigation questions.
  • Topic-aware conversation state — follow-up questions don't restart from zero.
  • Structured responses per query type: reply text, source links, navigation actions deep-linking into the map, and follow-up chips.
  • Controlled fallback: when confidence is low, it hands off explicitly to the Support page instead of improvising.
  • Rate-limiting built into the architecture from day one.

The supporting modules

📅

Campus events

Event browser with Google Maps directions, save/favourite, and Add to Calendar with fallback handling.

⚙️

Settings & profile

Microsoft-synced institutional identity (read-only) clearly separated from editable student fields.

💰

Funding & scholarships

Structured access to financial resources that previously meant digging through the university website.

Security & testing

JWT-based authentication with access control enforced at the architectural layer — and a testing plan that was part of delivery, not an afterthought:

30+tests conducted
⚙️functional & integration
🛡️simulated DDoS & flooding
🤖AI rate-limit validation
🚀validated on Vercel

Why I built it this way

Navigation as the entry state, not one module of many

The survey data was clear, so the architecture followed it: the first thing you see is the campus map and path selector. Everything else is reachable from there — which shaped the routing structure and let the AI assistant deep-link directly into map views.

An assistant that can't answer freely

A language model improvising answers about visa renewal deadlines or fee exemptions is a liability. Interpretation, grounding, safety, and rate-limiting live in separate logic files — not inside one prompt. The assistant knows which topics it can address reliably; outside those, it hands off to Support. That constraint is what makes it trustworthy.

Security testing planned before development finished

An AI assistant with no rate control is a budget problem the moment someone abuses it, and a campus app is a public-facing target — including large crowds during orientation. DDoS and flooding scenarios were tested because shipping without them would have left known risks unverified.

The mid-sprint settings redesign

Early testing showed users trying to edit Microsoft-synced fields, seeing no feedback, and assuming saves had failed. A form that silently ignores writes is a trust problem. The fix: two explicitly labelled sections — Account & Sync (institutional, read-only) and Student Details (user-editable) — so the interface promises exactly what the system does.

Outcome

A deployed progressive web application for Swinburne Kuching — built from direct student survey data, with 360° navigation as the core and AI-assisted support, events, funding, and profile management around it. 30+ tests across functional, security, and load scenarios before handoff.

The assistant architecture is modular: adding a new support topic doesn't require rewriting core logic.

Stack

TypeScript Next.js React Claude API 🔑 JWT Auth 🌐 REST API Vercel
Next case study Semangoh Park Guard System