CST 489 - Capstone Project Planning
Course Overview
CST 489 is the planning half of the CSUMB computer science capstone. Students write a detailed proposal for a substantial, professional level project, get it approved by a capstone advisor, and practice the project planning, collaboration, and technical writing expected in industry. The proposal has to define a real problem with a real external client, scope roughly 100 to 200 hours of work, and commit to deliverables the team will be graded against in CST 499.
My team of four was mentored by Justin Greenberg, founder of ComicSeen, with Dr. Bude Su as course instructor. ComicSeen is a live commercial booking platform for the stand-up comedy scene, so this was not a sandbox project. Everything we proposed had to be shippable into a production codebase with real users.
Course Outcomes
- Apply knowledge from the degree program to a real world problem of importance to an external client.
- Communicate with a client to gather requirements and develop a project proposal that meets them.
- Work in a team and apply the soft skills expected in professional environments.
- Break a large problem into smaller pieces and articulate the big picture behind it.
- Develop detailed plans, timelines, and testing strategies, then execute against them.
- Learn new technologies and approaches as needed to achieve project objectives.
Capstone Proposal: ComicSeen Platform Feature Improvements
Team: Yusra Ashar, Sam Numan, Shane Ritter, Vivian Le · Mentor: Justin Greenberg · My role: Team coordinator, notification system refactor owner, and proposal assembly
The problem
Comedy booking has historically been scattered across Facebook groups, text threads, email chains, and spreadsheets. Comedians have no professional producer-facing presence and no way to publish their availability. Producers spend time tracking performer information manually. Our environmental scan looked at Eventbrite, GigSalad, Facebook Groups, and Meetup and found that each solves an adjacent problem, ticketing or general entertainment booking or informal chat, but none handles the actual comedy workflow of a producer running shows, comics signing up, both parties communicating, and the right notifications firing at the right time. Meanwhile the live comedy industry has grown sharply, which makes manual coordination a real bottleneck rather than a minor inconvenience.
Proposed scope
We scoped four features into the existing React and Spring Boot codebase, one per team member, sharing a single authentication layer, user model, and database:
- Notification System Refactor (mine): move from tightly coupled inline email calls to an event-driven architecture using Spring ApplicationEvents.
- In-App Messaging System (Sam): real-time producer to comic messaging over WebSocket and STOMP with role enforcement.
- Calendar of Availability (Shane): comic availability scheduling plus producer-side search, filtering, and booking requests.
- EPK Profile (Vivian): a professional, producer-facing electronic press kit for comedians.
My planning work: the notification refactor
Before proposing anything I ran a six phase analysis of the existing codebase, three phases to map how notifications actually worked and three to design the replacement. The audit surfaced five specific tight coupling violations where email was being sent inline inside transactional business methods, blocking the HTTP request thread on an external API call. It also surfaced a live production bug: SHOWCASE_DROP_NOTIFICATION was defined in the enum, handled in the email service, and stored as a user preference, but never triggered anywhere, because the drop method never fetched the show and so never knew its type. That whole notification path was dead code.
The proposed design used a domain event per trigger, an ApplicationEventPublisher in the business services, and a listener annotated with @TransactionalEventListener(phase = AFTER_COMMIT) so no email can fire on a rolled back transaction, plus @Async on a dedicated thread pool so a slow or failed email provider never delays a user's signup response.
Where human judgment mattered
The proposal required a critical evaluation of AI-assisted development, which turned out to be the most useful section to write. The AI generated a technically sound architecture, but it did not know that our mentor had scoped us to Spring events rather than Kafka for a single app instance, it assumed a repository method existed without verifying it, it proposed broader changes than the client asked for, and it suggested @TransactionalEventListener without explaining the implication that a plain listener would have sent confirmation emails for failed signups. Deciding which callers to refactor and which to leave alone in a production codebase was a scoping call, not a code generation call.
Full Capstone Proposal (45 pages):
Mid-Semester Status Update
Mid-semester presentation delivered to Dr. Su and the course, covering progress against the proposal timeline, what each team member had implemented, and what remained for the build phase.
What I Took From This Course
The planning half taught me that the hardest part of a real project is not the code, it is agreeing on what the code is supposed to do. Writing a proposal for a live commercial product meant every feature had to survive a conversation with an owner who knew the domain better than we did, and several of my early assumptions did not survive. Reading an unfamiliar production codebase closely enough to find a dead notification path also changed how I approach new repositories: the interesting problems are usually in what the code fails to do rather than what it does.
Coordinating four people across four feature areas meant keeping the branches, the timeline, and the mentor check-ins aligned while still owning my own implementation. That balance between individual delivery and team throughput is the part of this course I expect to use immediately.