Students building for themselves — The software behind the CSXL

The premise

The people using it could be the people making it.

A student needs a monitor. A team needs a room. Someone is stuck on an assignment and needs help. A club wants people to find its next event.

These are familiar problems in a computer science department. They also make a compelling foundation for learning software engineering: the users are nearby, the needs are real, and a useful feature can become part of daily life.

The CS Experience Labs’ web application grew around that idea. Students designed and wrote software for themselves and their peers, then left it for the next students to extend.

A place
to work.

See available desks, reserve a room, and check in with an XL ambassador.

People
to work with.

Discover student organizations and the events they bring to the department.

A way
to get help.

Find course office hours, describe a question, and follow a help ticket.

A way
to contribute.

Apply to join a teaching team—or improve the application itself.

Spring 2023

Start with a shared foundation.

A software engineering pilot becomes the starting point for student features.

Summer 2023

Design it from Copenhagen.

Students explore how their own department’s shared spaces could work.

2023–2024

Put the work into use.

Organizations, events, room reservations, office hours, and applications reach main.

2024 onward

Inherit it. Improve it.

New teams add recurring schedules, statistics, signage, and refinements.

01 / Spring 2023

A course with
a real destination.

I began the shared application in March 2023, as Foundations of Software Engineering was taking shape through a COMP590 pilot. The course would become COMP423.

The starting point included accounts, permissions, a database, and a development environment. Angular in the browser, Python and FastAPI on the server, and PostgreSQL for storage gave teams a shared stack to build on.

Students work together at shared desks in the early App Lab. — The community came first. Students at work in the App Lab, September 2022, before the software project began. The story of the space ↗

Engineering for people you know.

A classroom project can end at a submission. Here, a successful contribution could become a service that classmates use the next semester.

That gives the engineering work a purpose. A feature needs a clear interface, data that survives a restart, permissions that make sense, and tests for what happens when things go wrong. It also needs to fit the work other students have already done.

March 11, 2023 / first commit ↗The shared development environment ↗

02 / Copenhagen · Summer 2023

Design the software
for your own space.

What would make it easy to find a place to work?

In COMP590: Design of Design in Copenhagen, students explored that question in Figma. Their June 2023 proposals worked through desks, monitors, group rooms, availability, reservations, and arrival.

They knew the setting they were designing for. The alternatives show how differently the same need can be understood: as a floor plan, a set of available resources, a calendar, or a sequence of decisions.

Students descend a long outdoor stairway beside CopenHill’s striking facade of stacked aluminum blocks. — **Look closely at the city.**Exploring CopenHill, Copenhagen.
May 24, 2023.

Students work with paper and small physical constructions around a shared table in a museum workshop covered with collage images. — **Think with your hands.**Making together during a museum visit in Ishøj.
June 1, 2023.

Two students lean together over sticker-covered laptops at an outdoor table in Copenhagen’s Reffen street-food market. — **Bring the work along.**Laptop collaboration at Reffen, Copenhagen.
June 4, 2023.

The Summer 2023 group, learning and making in and around Copenhagen. Photographs by Kris Jordan; tap to view full size.

Brynne Delaney’s dark interface shows overall capacity, a floor plan with green available seats, and study room choices.

Brynne’s group reservation screen asks when the group will meet and how many students need a room.

Brynne Delaney · June 2023

Make availability visible.
Then ask about the group.

A capacity indicator and a map help a student understand the room at a glance. A separate group flow asks for the day, time, and number of people before narrowing the choice.

The design connects two scales of use: finding one seat and finding a place to work together.

Explore Brynne’s archived designs

Sanaa Dalvi’s seat-selection map includes desks, round tables, named rooms, and pink availability highlights.

Sanaa Dalvi · June 2023

Let the place
be the interface.

Desks, round tables, and named rooms share one spatial view. Time labels sit beside the places they describe.

It is a concrete way to ask a familiar question: where do I want to work? The screen makes the relationship between a digital choice and a physical place visible.

Explore Sanaa’s archived designs

Keon Marcus’s reservation screen presents counts for seated desks, standing desks, and other seats.

Keon’s next screen offers a schedule for choosing a booking time.

Keon Marcus · June 2023

Start with
what is available.

Large counts and direct reservation actions make the resource types easy to scan. A student can distinguish a seated desk from a standing desk before choosing a time.

The proposal makes an important distinction explicit: some seats can be reserved, while other seating is first come, first served.

Explore Keon’s archived designs

Katherine Bryan’s room booking form filters rooms by date, time, and minimum capacity.

Katherine’s check-in proposal shows a sample personal QR code and instructions to visit the ambassador.

Katherine Bryan · June 2023

The reservation continues
at the front desk.

Room choices are filtered by time and minimum capacity. A separate check-in screen connects the reservation to arrival and the ambassador’s work.

The design follows the whole activity: make a choice, keep a record, arrive, and use the space.

Explore Katherine’s archived designs

Selected student proposals from June 2023. Tap a screen to open its archived PNG. Zoom in to inspect the detail, or download a copy. The production releases below are dated separately.

Explore all 16 students’ archived designs

The wider collection includes calendar flows, maps, group membership, reservation changes, and ambassador views. Each student’s exported screens are preserved together in a PNG hosted on this site. Open a sheet, then zoom in to read individual screens or download the image. No Figma account is needed.

A shared question

What does the student need to know next?

The summer designs made the problem tangible. In the application, the same questions would become connected screens, permission rules, reservation states, and database records.

03 / Fall 2023

Find your people.
Find a place.

The first student features made the site a way into the department’s community. Organization pages introduced clubs and ways to connect. Events gave those organizations a place to share what was happening.

Ajay Gandecha, Jade Keegan, Brianna Ta, and Audrey Toney—COMP423 final project group A3—developed the organization and event features. Their release notes credit the team together.

The early CS Organizations page uses searchable cards for UNC computer science student groups. — September 2023 / Organizations reach main. The original release screenshot shows the early dark theme and a searchable directory.

Organizations / PR #68 ↗Events / PR #114 ↗Event registration / PR #212 ↗

October 2023

From a room full of desks
to available places.

As the renovated Co-Lab came into use, the application gained coworking drop-ins. A student could see which kinds of seats were available, reserve a place, and check in with an ambassador.

The distinction mattered: a monitor-equipped desk, a standing desk, and a communal seat support different ways of working.

The coworking launch ↗

The October 2023 coworking interface lists available sitting desks, standing desks, and communal seats. — October 2023 build, recreated with demo availability. The outlined cards reflect the design consolidation in PR #128.

04 / March 2024

A room for
your next meeting.

The space was growing. The software needed to grow with it.

Team B8’s Fall 2023 COMP423 project became the room reservation feature, merged on March 8, 2024. Aarjav Jain, John Schachte, Nick Wherthey, and Yuvraj Jain built a way to choose a room and adjacent time slots, confirm the reservation, and see it again later.

The work joined a student’s plan for a meeting to the department’s shared inventory of rooms.

The first room reservation release presents rooms as rows and half-hour time slots as colored columns. — March 8, 2024 / The first release’s room-and-time grid. Recreated from the merged build with demo availability; the grid scrolls horizontally.

A release was
the start of the next conversation.

Jade Keegan’s review of the reservation PR raised questions a student would encounter in use: how to find upcoming reservations, how the grid would work on a phone, and whether the next action should say “Select” or “Reserve.”

Further changes brought the interface into the site’s Material conventions, corrected conflicting reservations, and added tests and documentation. The useful feature kept becoming a better piece of shared software.

Team B8’s work and review / PR #250 ↗Interface refinements / #332 ↗Tests and documentation / #434 ↗

01 / Interface

Choose a room.

Show availability, keep a selection coherent, and explain what is being reserved.

02 / Workflow

Hold, then confirm.

Represent a draft and a confirmed reservation as different states.

03 / Policy

Share it fairly.

Apply time limits and protect periods needed for office hours.

04 / Persistence

Keep the promise.

Save the reservation and reject a conflicting booking on the backend.

One familiar student activity reaches across the whole system. The architecture below shows how those responsibilities connect. The team’s specification records the models, services, interface decisions, and workflow; the conflict-checking fix shows why the backend also has to enforce the promise.

Inside the software / A shared map

From a click
to a lasting record.

Students work across the system they use.

Choosing a room begins in the browser, travels through an API, and becomes stored data. Each layer has a job. The shared architecture gives a new team a place to fit its feature and a way to understand what other teams have built.

Ajay Gandecha made that structure visible in his SQLAlchemy tutorial for the CSXL and COMP423, added in November 2023. The application became both something students could improve and something they could learn from.

In the browser.

Angular’s router chooses the page. Components combine HTML, CSS, and TypeScript; frontend services send HTTP requests and bring the results back to the interface.

Across the API.

FastAPI routes handle HTTP. Pydantic models describe and validate API data. Backend services apply the application’s rules, keeping those decisions separate from the screen and the request.

Into the database.

SQLAlchemy sessions work with database entities to read and write PostgreSQL records. Services translate those entities into API models. Information can survive a refresh, restart, or new deployment.

Why separate the layers? / Spring 2025 reading ↗API models and database entities ↗Ajay’s tutorial contribution / #173 ↗

Learning to build / COMP423

Learn the craft.
Build for people.

The semester moves from shared practice to shared responsibility.

The first-day framing is a boot camp followed by feature work in sprints. Students first develop a common foundation through readings, exercises, and collaboration. Then a team takes responsibility for a feature in an existing web platform.

In the CSXL offerings, the second half brought those skills together in software for their own department. The topics below use the Spring 2026 first-day objectives and course materials to explain the broader education behind that work.

01 / First half

Boot camp.

Build a working understanding of the tools and system: source control, reproducible environments, testing, HTTP APIs, service boundaries, and persistent data.

Students practice reading unfamiliar code, pairing, making small changes, and verifying their behavior. Across the CSXL offerings, this also means learning how an Angular and TypeScript client connects to a Python backend.

Spring 2026 lessons ↗Spring 2025 frontend and backend units ↗

02 / Second half

Feature development.

Design the feature. Identify the people, their goals, and the most useful stories. Sketch interactions and agree on data and API contracts.
Build one story through the system. Connect the interface, routes, services, and stored data in a working increment.
Polish, verify, and hand it off. Review changes, add tests, deploy, demonstrate the result, and document how another developer can extend it.

Six threads, woven through the work

What students learn in a feature.

01 / Professional growth

Career and lifelong learning.

Ethics, professional roles, independent learning, evaluating tools, and taking responsibility for work produced with AI assistance.

For a CSXL feature: learn an unfamiliar part of the application, justify a decision, and deliver a change you can explain and verify.

02 / Working together

Collaboration.

Technical communication, pair programming, git branches and merges, issues, project boards, pull requests, and thoughtful code review.

For a CSXL feature: agree on the API, coordinate changes to shared code, and review a teammate’s implementation before integration.

03 / Understanding the need

Design process.

Personas, requirements, user stories and epics, acceptance criteria, Figma wireframes, prototypes, scope, and trade-offs.

For a CSXL feature: turn “we need a room” into a booking flow that works for students, groups, and the ambassador at the desk.

04 / Connecting the parts

System design.

Client/server communication, HTTP APIs, validation, dependency injection, services, relational data, ORM sessions and transactions, and cloud deployment.

For a CSXL feature: connect a browser action to application rules and durable records, following the shared architecture.

05 / Demonstrating quality

Software engineering skills.

Modularity, architectural decision records, unit and integration tests, acceptance and end-to-end tests, mocks, fixtures, static analysis, and continuous integration.

For a CSXL feature: test a booking rule, an API response, and the complete user journey while protecting existing behavior.

06 / A professional workspace

Tool bench.

Dev containers, Docker, dependency managers and lockfiles, test runners, linters, debugging tools, and deliberate use of coding agents.

For a CSXL feature: reproduce the development environment, trace a request, run the team’s checks, and understand every change you keep.

The Fall 2024 project brief made the connection concrete: teams could tackle opening-hours editing, group reservations, usage statistics, or organization memberships. In Spring 2025, simulated service responses helped teams get a first story working before connecting persistence and integrations. The final sprint emphasized quality and documentation for future developers.

The feature is where the threads meet. Students design for their peers, build on others’ work, establish that their change behaves as intended, and leave something the next team can understand.

The six course threads ↗CSXL feature design assignment ↗

The course continues to evolve. Spring 2026’s feature project uses LearnWithAI; the CSXL examples here describe the earlier platform work. The shared pattern is learning the foundations, then contributing a feature to software used by a real community.

05 / 2024–2025 · Work that crossed teams

Getting help,
made together.

Multiple student teams worked on early versions of office hours, then continued improving the system.

The need was close to home: students needed a way to ask for help, and student teaching assistants needed a way to see and manage the queue. The system also had to know the course, its staff, its schedule, and where help was taking place.

The releases below trace several chapters of that shared work: the May 2024 implementation, a new home in My Courses, recurring dates, and tools for understanding and managing use.

The first Office Hours home page lists a student’s courses and an office hours event in SN156. — **May 2024 / A first home for help.**Original screenshot from the team’s feature specification.

The later office hours queue gives course staff a wider view of queued and called tickets with event information. — **August 2024 / A wider view of the queue.**Ajay Gandecha’s later redesign, preserved in PR #608.

Spring 2024

Build the ticket workflow.

Meghan Sun · Bailey DeSouza
Madelyn Andrews · Sadie Amato

The initial implementation brought course office hours, student tickets, and staff queues into the XL stack. Students could describe what they needed; staff could call a ticket and work with the student.

Initial feature / merged May 15, 2024 / #443 ↗

Summer 2024

Connect help to My Courses.

Ajay Gandecha, with continued review and integration

A reimplementation connected office hours to course sites. The student’s Get Help page and the staff queue became different views of the same activity. Course administration gained event editing and roster import from Canvas.

Office hours in My Courses / #501 ↗ · Course administration / #504 ↗

January–
February 2025

Make the schedule repeat.

Jade Keegan, with contributions from Ajay Gandecha and Kris Jordan

Weekly recurrence removed the need to create every meeting separately. Staff could choose weekdays and an end date, then create or delete a recurring series. The next increment added the choice to update one event or that event and the future events in its pattern.

Recurring dates / #652 ↗ · Update a recurring pattern / #683 ↗

Spring–
Summer 2025

Learn from use.
Improve the daily work.

Ajay Gandecha · Jade Keegan
Mira Mohan · Lauren Ferlito
Benjamin Eldridge

Further work added ticket statistics and CSV exports, links from the roster to a student’s statistics, and notification sounds. Instructors could configure ticket cooldowns and daily limits.

The contributors extended different parts of the experience: the queue, the schedule, the feedback available to course staff, and the small signals that help people know when it is their turn.

Statistics / #739 ↗ · Roster tools / #748 ↗ · Notifications / #699 ↗ · Ticket limits / #649 ↗

The recurring-date capability today

A weekly commitment,
entered once.

Monday and Wednesday, at the same time, through the end of the term. A recurring pattern turns that familiar teaching schedule into a set of office hours events.

It is a small form with a substantial idea behind it: the software can take care of the repetition, while course staff take care of students.

The office hours editor selects a weekly pattern on Monday and Wednesday, with an end date for the series. — The recurring-date controls in the October 2026 build, shown with an illustrative schedule. Recurrence first reached main in January 2025.

One team could make the first useful version. Later teams could understand it, reshape it, and take responsibility for what came next. That continuity is part of the software—and part of the education.

06 / A platform for the department

The next need
already had a home.

Once accounts, courses, organizations, rooms, and permissions existed together, new features could build on those relationships.

The application grew beyond reserving a place to work. It could support the work of the department: helping students find their courses, applying to a teaching team, sharing news, and showing what was happening in the lounge.

December 2023 → July 2024

From a catalog
to your courses.

The academics feature introduced courses, section offerings, terms, and rooms. My Courses then made that information personal: a student’s course sites could lead directly to office hours.

Ajay Gandecha developed the academics feature and much of the later course experience, alongside the shared infrastructure and integration work.

Academics / #222 ↗My Courses / #499 ↗

My Courses organizes course cards by term and gives each course a Get Help action. — A later view of the capability: My Courses in the October 2026 build, recreated with illustrative courses.

April → July 2024

Apply to be part
of a teaching team.

Ben Goulet’s UTA application feature brought the application process into the XL in April 2024. The application could connect a student’s information and course preferences to a teaching opportunity.

In July, Ajay Gandecha reimplemented the forms and extended the feature to graduate TAs. Application review and hiring tools grew alongside it.

UTA applications / #402 ↗UTA and GTA forms / #529 ↗Application review / #517 ↗

The early UTA application form asks for student information and teaching preferences. — The early application form, preserved in Ben Goulet’s April 2024 specification.

March 2025

Bring the information
back into the room.

Andrew Lockard, Will Zahrt, and Audrey Toney built digital signage for the XL lounge. The display brings together seat and room availability, news, events, and office hours queues.

The software returns to the physical place it serves. A student standing in the lounge can see information that previously lived on separate screens.

Lounge signage / #697 ↗

The lounge signage combines occupancy, room availability, news, events, a leaderboard, and office hours. — March 2025 / A shared display for the shared space. Original development screenshot with sample content.

07 / Building something others can inherit

The next students
need a way in.

A growing application needs a shared visual language and a codebase people can understand. Design consistency, documentation, and maintenance became contributions in their own right.

They make it possible for another student to take a useful next step.

A shared Figma canvas collects connected designs for organizations, courses, office hours, coworking, and welcome pages. — A shared Figma reference brings the application’s screens into one view. The date and individual authorship of this copy are not established. Original Figma file ↗

A common language,
across features.

The site’s design evolved from the early blue navigation and outlined cards into a more cohesive Material 3 interface. Ajay Gandecha’s June 2024 upgrade established a new visual foundation, followed by refinements to individual features.

The welcome page made news, opening hours, reservations, and event registrations part of a connected arrival experience. The shared design file shows how these pieces relate.

Later maintenance kept the application moving with its tools, including Angular upgrades and a 2026 styling refactor. The work continued after the first releases.

Material 3 / June 2024 / #493 ↗Welcome and news / July 2024 / #539 ↗Styling refactor / January 2026 / #826 ↗

Explain the system.

Feature specifications describe what was built and how it works. Ajay Gandecha’s tutorials and architecture diagram give future students a shared map of the application they are learning to extend.

Review a real change.

Branches and pull requests give the team a place to discuss behavior, design, tests, and integration before a change becomes part of the shared application.

Leave a useful next step.

A bug fix, a clearer error, a better test, or a simpler component can matter to everyone who uses or develops the system afterward.

Branching and review practices ↗Learning through the application ↗Contributing guide ↗

The capability students have now

A platform
they can keep making.

The result is useful software for a community—and experience making something that matters to that community.

Students can work in the spaces, join the organizations, use the office hours system, and apply to teach. They can also understand how those services work and help change them.

That is the thread from the Copenhagen wireframes through the COMP423 projects and later releases: students taking an active part in designing the environment they learn in.

Find a workspace.

Check coworking availability and reserve shared rooms.

Connect with people.

Discover organizations, events, and opportunities to participate.

Ask for help.

Find course office hours and follow a help ticket.

Support a course.

Manage queues, recurring schedules, rosters, and ticket statistics.

Join a teaching team.

Use applications and the department’s teaching assignment workflow.

Build what comes next.

Work with a shared codebase, design references, documentation, and review.

Visit the CSXL ↗Explore the software ↗The story of the space ↗

Sources, credits, and how to read the images

This is a selected history of the CSXL application through October 2026. Release dates describe changes merged to the repository’s main branch; they do not imply every capability was immediately in use by every course. Dates are presented in US Eastern time.

Design credits

The summer 2023 Copenhagen work is credited to the students named beside the images and in the design directory. Those credits come from the course archive supplied by Kris Jordan. All 16 design files were reviewed and their exported screens are archived as PNGs on this site. The archive sheets arrange the exported screens for browsing without resampling their pixels. Smaller WebP previews keep this page quick to load; opening a design loads the PNG. Proposed screens and their placeholder data describe design explorations.

The separate XL Coworking Application wireframes and shared CSXL design template were supplied by Kris Jordan. Individual authorship of those two files is not assigned here. The student proposals are not presented as a one-to-one account of authorship of the later production code.

Release and contributor evidence

Organizations #68 and events #114 explicitly credit Ajay Gandecha, Jade Keegan, Brianna Ta, and Audrey Toney. Event registration #212 records the next increment.
Room reservations #250, its review, and the feature specification establish Team B8’s work and authors. #434 records later testing and documentation.
Initial office hours #443, My Courses office hours #501, recurrence #652, recurrence updates #683, and statistics #739 document successive bodies of work. Statistics contributor names are also recorded in the merged commit’s coauthor credits.
UTA applications #402, extended applications #529, and signage #697 document further department capabilities. Signage authorship is recorded in its source and release.

Architecture and course materials

The architecture diagram is Ajay Gandecha’s original client/server diagram with SQLAlchemy, introduced in PR #173 on November 17, 2023. The full-resolution PNG is hosted here unchanged, with smaller WebP previews. It is a teaching diagram from that period, including its CloudApps hosting label.

The Fall 2024 and Spring 2025 course materials document project prompts and learning expectations. The course narrative cites those assignments; it does not imply every proposed or submitted feature was merged into the department’s production application.

The course overview follows the six threads and two-phase structure in the Spring 2026 first-day slides. Topic details draw on that offering’s lessons on tools and code review, testing, API design, ORMs and transactions, and Angular frontend development. The CSXL applications of those topics are illustrative examples; Spring 2026’s feature platform is LearnWithAI.

Historical screenshots

Original development screenshots are preserved from the linked PRs and repository specifications. They show sample content. The welcome image omits the browser chrome; selected office-hours views are cropped to the relevant application content.

The October 2023 coworking view is recreated from 33f0934; the March 2024 reservation view from b13e6dd; and the October 2026 My Courses and recurring-date views from 9cc2433. These are actual historical frontend builds, captured in 2026 with illustrative demo API responses. They are not records of occupancy, reservations, or enrollment. Container-specific import paths were adapted in temporary copies to run locally.

The September 2022 photograph is reused from the companion space retrospective. Software contributor credits are selected examples, not a complete contributor roll. The repository history records a wider community of work. The source is MIT licensed.