Case study — 02
University web systems
Study-program sites, directorate portals, and the maintenance work behind them
Day-to-day development and operations for the public web presence of Universitas Ubudiyah Indonesia — six study-program sites, four directorate portals, and the internal systems staff use.
- Role
- Programmer — development and maintenance
- Period
- 2025 — present
- Status
- Ongoing
/ Internal systems, credentials, and private URLs are not published. The sites listed on this page are public.
Context
Universitas Ubudiyah Indonesia runs a lot of small web properties. Each faculty and study program expects its own public site; each directorate expects a portal for news, documents, and services. They are not a single product with a single roadmap — they are a set of sites with different owners, different content editors, and the same small team maintaining them.
I work on that set as a programmer: building new sites, extending existing ones, and keeping them online through the academic year.
What I work on
Public study-program and faculty sites. The Faculty of Health Sciences site and six program sites — Pharmacy, Public Health, Nutrition, Psychology, and two Midwifery programs. They share a design language and content structure, but each has its own academic information, staff, and facilities to present.
Directorate portals. Research and community service, quality assurance and accreditation, partnerships and careers, and the faculty laboratory system. These are closer to small content platforms: news, document libraries, accreditation data, job listings, and public search.
Internal systems. Registration, exam delivery, reporting, and administrative tooling used by staff. These are the systems that do not appear on a public portfolio, and the ones where a broken release is felt immediately.
The public sites
| Site | Type | What it covers |
|---|---|---|
| fikes.uui.ac.id | Faculty | Profile, academics, facilities, news |
| dirpm.uui.ac.id | Directorate | Research, publications, community service |
| dpmpa.uui.ac.id | Directorate | SPMI documents, audits, accreditation |
| dk2mka.uui.ac.id | Directorate | Career centre, listings, alumni |
| labfikes.uui.ac.id | Laboratory | Equipment, SOPs, practicum schedules |
| tps.uui.ac.id | Platform | TOEFL prediction exam and certificates |
How the work is structured
Most of these sites are content-heavy and interaction-light, so the architecture stays deliberately small:
- Server-rendered pages first. Public content should be readable without a JavaScript bundle finishing. Interactivity is added where a workflow needs it, not by default.
- Shared components, separate content. Study-program sites reuse layout and navigation, but content is owned by the program. That keeps six sites consistent without forcing them into one editor.
- A single deployment path. Each site is a build artifact served behind a reverse proxy, which makes rollbacks and TLS predictable.
- Editors are the users. The interface is designed for staff who update news and documents weekly, not for developers. If publishing requires a developer, the system has failed.
Maintenance is the job
Launching a site is the short part. The rest is:
- Content and layout fixes requested by faculty and directorate staff.
- Keeping dependencies and runtimes patched without breaking published pages.
- Diagnosing slow pages and failed uploads from logs rather than guesswork.
- Restoring service when a certificate, proxy rule, or container misbehaves.
- Migrating content when a program reorganises its information.
That work is less visible than a launch, but it is what makes the public sites reliable. A department site that is down during registration week is a real problem, not an inconvenience.
Network and infrastructure
Alongside the web work I help maintain campus network and server infrastructure: Linux hosts, container configuration, reverse proxying, TLS, and the day-to-day operations that keep services reachable. My vocational background in computer and network engineering is directly useful here — when a site is unreachable, the cause is as likely to be DNS, routing, or a firewall rule as it is to be application code.
Constraints worth naming
- Confidentiality. Internal URLs, credentials, and infrastructure details are not published. What is described here is the shape of the work, not the institution’s private architecture.
- Non-technical editors. The interface has to survive being used correctly by people who are not developers, and incorrectly by people who are in a hurry.
- Academic calendar. Some weeks cannot be disrupted. Deployments are planned around them.
- Small team, many properties. Reuse is not an aesthetic preference; it is the only way to maintain this surface area.
What I learned
Consistency beats customisation. The program sites that share a structure are cheaper to maintain and easier for visitors to use than the ones that were allowed to become unique.
Operational clarity is a feature. A clear deployment, a readable log, and one place to change configuration save more time than any UI improvement.
Writing for editors matters. The content model is part of the product. If the fields do not match how staff think about their information, they will work around the system.
Public sites are institutional infrastructure. They are the first contact point for prospective students and the last place you want an outage.