CST 499 - Computer Science Capstone
Course Overview
CST 499 is the build half of the capstone. Teams take the proposal approved in CST 489 and deliver it: requirements specification, solution plan, design, implementation, testing, and a final demonstration. The course runs like a work environment, with faculty acting as project manager and students expected to be self directed, make measurable progress each week, and raise blockers rather than sit on them.
My team built into ComicSeen, a live commercial booking platform for the stand-up comedy scene, mentored by founder Justin Greenberg. All four proposed features were completed, merged, and deployed. The platform is in production and used by working comedy producers and comedians.
Course Outcomes
- Apply software engineering skills to a real world project with an external client.
- Solve problems without step by step instructions, breaking a large objective into deliverable pieces.
- Evaluate work incrementally and improve quality through iteration.
- Collaborate with a team and a client through a professional version control and review workflow.
- Learn new technologies and techniques as the project requires them.
- Prepare for a professional career through a resume, LinkedIn profile, portfolio, and career development plan.
The Live Platform
ComicSeen is a working product used by comedians and producers. All four features described below shipped into it.
The source is a private, client-owned codebase. Under our Student Software Development Agreement the repository and company IP remain the property of ComicSeen, so it isn't published here.
What the Team Shipped
Four features, one codebase. They share the same authentication layer, user model, and database, so they are integrated parts of one product rather than four separate add-ons. Messaging, signups, and the show and booking flows all publish into the same notification pipeline, so a new message, a signup, or a cancellation travels one shared path.
- Notification System Refactor (Yusra Ashar): event-driven notifications on Spring application events, six event types wired end to end.
- In-App Messaging System (Sam Numan): real-time producer to comic messaging with role enforcement, unread tracking, and email alerts for offline recipients.
- Calendar of Availability (Shane Ritter): comedian availability scheduling plus producer-side filtering and a booking request workflow.
- EPK Profile (Vivian Le): redesigned comedian press kit and edit experience, plus frontend test coverage wired into the deployment workflow.
My contribution: the event-driven notification system
I replaced a tightly coupled notification model, where email was sent inline inside transactional business methods, with an event-driven system built on Spring application events. Business services now publish a domain event and know nothing about email. A listener resolves the recipient, checks that user's notification preference, and only then sends.
- Six event types wired end to end, covering signups, drops, bookings, show cancellations, and add, remove, and replace lineup changes.
- Delivery gated on
@TransactionalEventListener(phase = AFTER_COMMIT), so a rolled back transaction can never produce a misleading confirmation email. - Email moved off the HTTP request thread with
@Asyncon a dedicated bounded thread pool, so a slow or failing email provider no longer delays a user's signup response. - Fixed a live bug where showcase drop notifications were permanently dead code, by carrying show type into the event and branching at a single point for both the preference check and the email method.
- Wrote a 22 test backend suite covering preference filtering, event dispatch, and the transaction boundary behavior.
Scope changes during the build
The core objectives held, but scope moved with the mentor. Notifications expanded to include show cancellation and lineup change emails. Messaging grew to cover producer to producer conversations. Availability moved to phased delivery: the dashboard calendar shipped to production while the booking workflow, though feature complete, waits behind an upcoming paid subscription tier, a sequencing decision by the platform owner. Testing also grew well beyond the unit tests we originally proposed.
Testing and Evaluation Report
We ran moderated usability sessions with four testers matched to the platform's two personas. Abdullah tested the producer workflow. Aline, Sabrina, and Steven acted as comedian-persona testers. Each tester thought aloud while a team observer took notes, exercising the workflows on the live production platform, with the availability booking workflow tested on a development build. I coordinated the sessions and assembled the report, with each member authoring the results for their own feature area.
Results
- All four testers completed every assigned task. No task ended in failure.
- Testers observed the full notification loop live: an email on message receipt, an unread badge appearing in real time, and the show lifecycle emails arriving within moments.
- Role-based access worked as intended, with searches correctly scoped to producer and comic pairings only.
- Two consistent friction points surfaced. Three testers clicked Sign Up and landed on the Login page, traced to the homepage button pointing at the show-slot signup route instead of registration. And after a producer booked comedians, their dashboards did not reflect the booking, so comics had to search for the show to confirm they were on the lineup.
- Two testers paused at the term EPK without knowing what it meant, which is a labeling problem rather than a design one.
Changes driven by testing
Before the festival: route the Sign Up button directly to registration, and surface bookings on the comedian dashboard. Longer term: introduce the EPK term with a plain explanation, add an in-app notification center and settings, deploy the booking workflow with the subscription tier, and pursue the EPK interface refinements, which need the platform owner's approval since they change a live product.
Full Testing and Evaluation Report:
Project Archive and Source Code
The ComicSeen repository is private and owned by our industry mentor, who runs ComicSeen as an active commercial business. The codebase is his intellectual property and handles real user data, so it cannot be redistributed outside his ownership. We confirmed this constraint with him directly.
Rather than excerpt fragments of proprietary source, the team documented the work through three forms of evidence that can be verified without repository access: the deployed product itself at comicseen.com, pull request records for each team member showing every change they made across the semester, and the testing and evaluation report above.
What I Took From This Course
Shipping into a production codebase with real users changed what "done" meant. A refactor that works on my machine is not the deliverable. The deliverable is a change that cannot send a confirmation email for a signup that failed, cannot block a user's response on a third party API, and does not break the five other things touching the same pipeline. Most of my engineering judgment this semester went into transaction boundaries and failure modes rather than features.
The usability sessions were the other lesson. Every tester finished every task, which could easily have been read as a clean result, but watching three of them click the wrong Sign Up button in a row surfaced a real defect that no test suite would have caught. Working with a client who owns the product also meant accepting that some completed work ships on his schedule rather than mine, which is closer to how engineering actually works than any previous course.