Nonprofit operations backend

Operation Surf

The backend had to reflect real event coordination: what is public, what is private, what admins can see, and how volunteers actually register.

Operation Surf is a nonprofit operations platform for coordinating programs, shifts, volunteer profiles, and signups. The case study is not just about CRUD; it is about shaping data flows so staff and volunteers see the right information at the right time.

The strongest backend work lives in the API boundaries: filtering private program data, enriching signup responses with shift/program details, trimming admin-only fields, and validating inputs that have real operational meaning.

600 volunteers55% data-fetching complexity reductionaccess-aware CRUD

View source repo Resume context

This project appears under Projects on my resume.

Operation Surf hero image — Nonprofit operations context: coordination software supporting real-world events.

System flow

Coordination data flow

01auth context
02route filter
03Mongoose query
04enriched payload
05role-aware response

API boundaries and permissions

One shaped response replaces scattered frontend joins.

The backend owns access rules and returns coordination-shaped data before the UI sees it.

Before

frontend fetches volunteer

frontend fetches shifts

frontend fetches programs

frontend joins manually

After

single enriched API response

admin-only fields removed from public payloads

signup responses include shift and program context

User typePublic programsPrivate detailsEdit shiftsManage signups

Public visitorYesNoNoNo

VolunteerYesLimitedNoOwn

AdminYesYesYesYes

GET /api/programsGET /api/signups/:idPOST /api/volunteersPATCH /api/admin/shifts/:id

Program has many Shifts

Volunteer has many Signups

Signup belongs to Volunteer and Shift

Project artifacts

Evidence you can see.

Real project media appears where available, with placeholder cards only where sanitized screenshots are still needed.

Operation Surf participant and instructor on surfboards during a water session — Figma reference image showing the in-water program workflow the operations platform supports.

Operation Surf participant sitting on a surfboard in the ocean — Figma reference image connecting volunteer coordination to the participant experience.

Public project identity asset, safe to show without volunteer data.

Logo asset used to keep the case study tied to the nonprofit context.

Operation Surf wave artwork — Non-sensitive visual context for the organization.

Technical deep dives

The UI should not be the only permission boundary.

Access belongs in the API

The API builds an auth context from the session and environment-defined admin identifiers. Program and day queries then filter private data for unauthenticated users, so access rules are enforced before data leaves the server.

Unauthenticated program requests filter to private: false.
Admin checks support both user IDs and email allowlists.
Volunteer payloads are shaped differently for admin and non-admin users.

Source sectionAuth context source Source sectionVolunteer API route

A signup ID alone is not what a volunteer needs to see.

Read models match user workflows

The registered-shifts view joins signups to day and program records, returning a payload that is directly useful to the frontend. That avoids making the UI reconstruct coordination context from multiple unrelated responses.

Signup routes collect shift IDs, then fetch matching day documents.
Program records are indexed by programId before response construction.
The response includes shift timing and program title/location context together, reducing data-fetching complexity by 55%.

Source sectionSignup API route ScreenshotSanitized screenshot placeholder

A false waiver value is valid data, not a missing field.

Validation has domain meaning

The signup route explicitly handles the waiver boolean so false does not get rejected by a generic truthiness check. That small branch matters because operational data often has meaningful false values.

Required-field validation special-cases waiver === false.
Signup timestamps are generated server-side.
Signup IDs are generated with crypto.randomUUID for stable references.

Source sectionSignup model

Animated artifact

API routes enforce coordination boundaries

The workflow diagram shows access decisions happening at the route/data layer before payloads reach the UI.

auth contextroute filterqueryenrichrole payload

Code evidence

Short excerpts that show the design choices.

Snippets are trimmed for readability and paired with the source file they came from.

const payload = authContext.isAdmin
  ? volunteers.map(toAdminVolunteerPayload)
  : volunteers.map(toNonAdminVolunteerPayload);

The route does not rely on the frontend to hide sensitive fields. It returns different data shapes based on server-side auth context.

Source sectionOpen volunteer route

const shifts = await Day.find({ dayId: { $in: shiftIds } });
const programs = await Program.find({ programId: { $in: programIds } });

return signups.map((signup) => ({
  signupId: signup.signupId,
  shift: shiftById.get(signup.shiftId),
  program: programById.get(programId),
}));

This turns normalized database records into the workflow-shaped response the UI needs for volunteer coordination.

Source sectionOpen signup route Source sectionProgram schema

Outcome and reflection

What this project proves.

Moved the case study focus from generic CRUD to access-aware operations design.
Showed how backend response shape can reduce coordination burden for real users.
Captured concrete API-level examples without exposing private volunteer data.

Operation Surf shows my backend thinking: data models are not neutral. If the API mirrors how people coordinate work, the software reduces friction instead of creating another admin chore.