UC Santa Cruz

A $XX million teaching budget, planned across XX spreadsheet tabs

The Situation

Every year, UC Santa Cruz’s Physical and Biological Sciences Division decides what it will teach. Eleven departments, about XX course sections across Fall, Winter and Spring, roughly XX instructors, and an instructional support budget of about $XX million that has to cover all of it. That work used to run on CCLP, the division’s curriculum and leave planning database. When CCLP was retired, a Google spreadsheet took over.

It grew to XX tabs. Every department had a data tab, and then a second tab summarizing the first. One combined tab pulled everything together, and a duplicate of that tab existed only to feed a single report. None of that was anyone’s mistake. A spreadsheet cannot be in two shapes at once, so every view the division needed became another tab that somebody had to keep current.

The cost showed up in the details. A cross-listed course appears under two subject codes, and whether its enrollment and TA cost got counted once or twice came down to who was editing that week. Reconciling with accounting took months. And the knowledge of how it all fit together lived with the few people who maintained it.

What Changed

About XX department managers now maintain their own course and budget data directly, and the division office reviews instead of merging. The bottleneck at the center is gone, along with the risk that sat with whoever owned the master file.

Every change is recorded with who made it and when. When accounting asks why a figure moved in March, there is an answer, and finding it takes a moment rather than an afternoon spent comparing versions. At the points in the year when the numbers need to hold still, the division takes a snapshot and reconciles against a fixed picture instead of a document that keeps moving underneath it.

The system understands what a cross-listed course is. It knows that two instructors can share one course, and that a TA on a cross-listed section is paid by one department while teaching under two subject codes. Those rules live in the software now rather than in the memory of whoever is doing the entering, and the totals come out right without anyone reconstructing them by hand.

The main planning view puts Fall, Winter and Spring side by side, because that is how the division already thinks about a year. XX years of enrollment history came across with everything else, so the past is still there to plan against. Accessibility was a requirement from the first design file rather than a retrofit, which matters to any campus commissioning new software.

How It Was Built

React and Next.js over Postgres, in a strictly layered architecture: server actions validate input, services hold the business rules, and every database query lives in a repository behind them. The audit trail is captured by Postgres triggers rather than application code, so nothing writes without leaving a record. Tests run against an in-memory Postgres, so schema changes surface before they ship. The application deploys in containers to staging and production, behind campus single sign-on, with role-based access scoped by department. Interface components are built on accessible primitives to a WCAG 2.1 AA standard.

Beezwax built it with agentic development, roughly five months from spec to launch, faster than a conventional build of this scope would have allowed. That speed went into shipping more of the division’s planning workflow rather than less.