Beyond the Localhost: Building Systems for People

ICS 314 · Dennis Sarsozo · August 2026

Before I started ICS 314, I was already working as a software engineer. I understood the basic idea: take human requirements and figure out how to use computers to provide a service or fix a problem. I knew about data transformation, programming languages, and industry standards. But there is a real difference between writing code that runs on your local machine and building a software system that a team can deploy, maintain, verify, and improve based on real user feedback.

The fullest expression of this difference was our final project: Mānoa Club Compass, a UH Mānoa club directory. It was a vague but potentially useful idea—a centralized directory for student organizations where students can browse, search by name or description, and filter by interest area. We built it using a stack of Next.js, Prisma, PostgreSQL, React, and Bootstrap, then deployed it through Vercel.

The real question wasn’t just “will the code work?” The real question was whether we could use everything we learned to work as a team, use Agile, and actually make the project happen. We did.

The Difference Between Code and a System

In a class exercise, the goals are clear: you either did the task or you didn’t. Projects are messier than exercises. Because we were working in a team, we had to deal with people, last-minute work, clarifying ownership, and figuring out exactly who was doing what.

The difference between code working and a usable system showed up constantly during our final project. Something might work perfectly on my computer, but then a teammate would ask why the Vercel deployment was failing or ask for logs. This taught me that a project must be more than just functional; it has to be deployable, maintainable, readable, and workable by other people. We used Prisma, PostgreSQL, and GitHub/CI workflows because they gave us a practical way to collaborate without quietly breaking the shared build.

The Lesson of the Shareable URL

One of the most useful lessons came from the gap between how we thought the software worked and how a user would actually interact with it. During community testing, we found edge cases that we simply had not seen while looking at the code.

For example, a student might use the search and filters to find a specific club. It looks great on their screen. However, if they copy that URL to share it with a friend, they would find that the link simply points to the main directory, showing all clubs rather than the specific filtered result they were looking at. The filter state should have been shareable in the link. This was a requirement we would never have found just by looking at the code or testing on a single machine; it was a requirement found only through the lens of human behavior. This taught me that the “user requirement” is often hidden in the way people expect to navigate the world.

Fundamentals in an AI-Assisted Workflow

In the modern era, AI has changed how I implement things. It helps a lot, but it has also changed the importance of fundamentals. I think about HTML and CSS—at first, they felt tedious. However, I realized that fundamentals matter more now than ever because of AI. If I know how a list element or a layout works, I can ask AI for the right thing and, more importantly, I can judge the answer instead of just hoping it figured everything out.

I love AI, but the final engineering call is mine. I still have to verify everything before pushing and make sure the code communicates what I am doing. The ability to use AI effectively depends on the ability to verify the output against the reality of the system.

From Web Frameworks to CubeSats

The transition from this kind of web development to embedded systems or CubeSat work might seem like a leap, but the transfer of knowledge is clear. The biggest connection lies in requirements and interfaces.

Satellite development is more waterfall-centric because hardware and mission requirements are serious constraints. In that world, we define what hardware and software must do from mission requirements, build it, verify it, and de-risk it. Web work is more Agile, but the fundamental need to refine requirements and test them remains the same. Whether you are deploying a React app to Vercel or code to a satellite, the necessity of defining interfaces and verifying that the system meets the human requirement is the core of engineering.

Advice for the Next Iteration

If you are a future ICS 314 student, know that this course teaches more than just modern web development frameworks. It teaches the practical habits of software engineering. The most valuable habits are small iterations and constant testing. Version control and code standards remain useful before and after the class ends.

As we moved through the project, we had to address community feedback—including incomplete profile information, missing result counts, page metadata/headings, and the need for a club-claim workflow. Those are the kinds of improvements that become visible once people use the system.

My advice is to embrace the messiness. Do not just focus on the code working on your machine. Focus on the system: how it deploys, how it handles the user who shares a link, and how it survives the hands of a team. That is where real software engineering begins.

A Note on AI Use

I recorded my initial ideas as voice notes, then used ChatGPT/Codex for transcription cleanup and a local Gemma LoRA model for a separate revision draft. The experiences, project examples, opinions, and final review are my own.

Written for ICS 314, Software Engineering I. University of Hawaiʻi at Mānoa, Summer 2026.