Building the website and working home for MSU ISA

Start with the people on either side of the website

A student attending an event should be able to find it and register without joining an administrative system. An affiliate representative needs a different view: their organization’s attendance, funding history, and collaboration proposals. Finance and Events staff need the information relevant to their work.

I built those experiences within one Next.js and Supabase application. The public site handles discovery and registration; the portal connects the records and decisions behind them. Someone signing up for an event becomes an event registration, while permanent portal access comes through an invitation.

That distinction keeps the public experience simple and gives the organization a more deliberate way to manage responsibility.

Follow an idea from proposal to public event

One of the most useful connections is between affiliate collaboration and event planning. An affiliate can submit a proposal, Events staff can review it, and an approved proposal can become a draft event or link to an existing one.

I kept collaboration and funding as separate decisions. Agreeing to work together does not automatically approve a budget. Funding has its own application and review process, including revisions, invoices, and payment confirmation. The software needs to preserve those distinctions while still letting staff see how the work connects.

The handoff to a public event also needs care. A proposal may contain private answers or internal feedback. Creating a draft carries forward the useful event connection without publishing those answers. Staff write the public description and choose when it is ready to go live.

Make organizational rules visible in the workflow

Affiliate attendance and funding eligibility are connected in ISA’s operations. That meant the platform needed to record who was expected at a meeting, what attendance was recorded, and whether the outcome affected funding.

An early meeting exposed a gap: recording an absence was not enough if the system had never recorded the affiliate’s attendance requirement. The fix connected meeting creation to the required organizations and added a grace period for corrections before final absences affected eligibility.

The broader lesson was about translating an organizational process into software. A rule needs a clear starting point, a person responsible for corrections, and a way to explain the outcome later. Staff also need a deliberate route to restore eligibility when appropriate.

Leave room for how events actually run

Not every event needs a hard cutoff at capacity. I added a soft threshold that keeps registration open while marking later signups as overflow. Changing that threshold affects future signups rather than rearranging people who have already registered.

Staff can also reopen registration before an event starts with a new deadline and a recorded reason. These controls acknowledge that plans change. The platform should help the team make an intentional correction rather than force them to work around the system.

For event-day use, registration ledgers provide search, filters, affiliation context, and exports, while staffed check-in has a more focused roster. Keeping those screens distinct helps each person find what they need for the task in front of them.

Make it feel like ISA

The public site uses ISA’s green and gold identity, campus imagery, and a responsive layout. I wanted it to feel connected to the student organization it represents. Event information and calls to action need to be clear, with the visual identity supporting them.

The portal received the same attention to everyday use. I worked through shared form layouts, field alignment, filters, loading states, and empty sections. Consistency mattered across funding, invitations, meetings, and events because staff move between those tasks.

From a prototype plan to a live platform

The original target was a working prototype by mid-October. The project reached a production release before that target and now lives at msuisa.org, connecting public events, registrations, affiliate operations, and funding workflows.

The next stage is operational use: more real event content, broader rehearsal with staff roles, and a lasting ownership plan. Launching the software gives ISA a foundation; maintaining it through changing student leadership is part of making that foundation useful.

For me, the project has been a chance to turn organizational responsibility into a product. The important decisions have been about what people need to do, what information they need to see, and how the next person can continue the work.