The Spreadsheet Labyrinth

During my internship at UPT Data & Informasi between my second and fourth college semesters, our team took on an internal automation project for a separate campus body: the university quality assurance board (Lembaga Penjaminan Mutu). Every year, the board conducts comprehensive internal audits across dozens of study programs to evaluate faculty performance, curricula, and institutional standards.

Before this project, the audit ran almost entirely on spreadsheet files passed between auditors and faculty heads over chat apps and flash drives. These were far more than simple checklists. Each study program maintained its own spreadsheet template with nested evaluation rubrics, variable scoring weights, and manually written cell formulas pointing to absolute coordinate references.

A single faculty member accidentally editing an index cell would silently corrupt an entire department's score calculation. When scores were submitted, auditors had to manually verify that the underlying formulas had not been altered. The primary objective was to replace this fragile exchange with a single source of truth backed by strict role-based access control and database validation.

The Architectural Whiplash

The technical stack went through three distinct phases, driven by changing institutional requirements rather than pure engineering preference.

We began with a standard monolithic setup in Laravel and Blade. As the team started modeling the audit evaluation screen, the sheer depth of the nested rubrics—real-time subtotal calculations, dynamic evidence attachments, and nested criteria trees—felt increasingly clunky to manage through traditional server-rendered templates. To give auditors an interface that updated responsively without full-page reloads, we refactored the presentation layer to React via Inertia.js.

The React interface solved the interaction problem, but institutional reality soon pushed back. Later in the development cycle, university leadership decided this audit system could not remain an independent web application. It needed to merge directly into the central university management portal, a legacy platform built and maintained strictly on Laravel and Blade.

Because the campus infrastructure team lacked the operational setup to maintain modern client-side bundles within their existing monolithic deployment pipeline, we had to make a pragmatic decision: swallow our technical preferences and migrate the entire frontend back to Laravel and Blade. Refactoring the rubric tree and calculation views back to server-rendered Blade templates added substantial development time, but it ensured the application could actually live within the campus ecosystem once deployed.

Generalizing Heterogeneous Instruments

The core data problem was finding a database structure capable of representing contradictory evaluation rubrics without creating custom database tables for every faculty.

Engineering and medical programs evaluated performance across fundamentally different metric trees than humanities or design faculties. We modeled the evaluation structure in MySQL through a tiered hierarchy: parent audit cycles, configurable instrument rubrics, nested assessment criteria, and independent score weights. This allowed auditors to define distinct evaluation formulas at the database level rather than hardcoding business rules into application controllers.

Early in the project, we also explored an experimental pipeline written in Python using FastAPI. The prototype ingested raw faculty spreadsheets, extracted cell dependency graphs, and automatically generated matching database records. While the script successfully processed sample files in development, I made the conscious call not to deploy it into production. Introducing a secondary Python runtime would have added unnecessary operational overhead for the campus maintenance team, especially with my upcoming departure. The parsing logic was kept as a reference script, and the system relied on native Laravel import workflows instead.

Handover and the Cost of Unclear Planning

By the time my internship ended, the core audit engine was operational: administrators could configure audit periods, assign auditor teams to specific faculties, collect evidence submissions, and review scores through centralized dashboards. Because the project had not reached complete institutional rollout when I resigned, I documented the schema design and handed the codebase over to the incoming intern cohort for final integration.

Working on this system for over a year reshaped how I think about engineering effort. The hardest part of software is rarely writing the code itself; it is navigating unclear boundaries and unaligned stakeholders. Starting development before the integration target was locked cost us multiple full-stack rewrites. I learned that upfront planning, explicit contracts, and honest alignment with the teams who will inherit your work are the highest-leverage investments an engineer can make.