Campus2Care

Campus2Care is a student-led 501(c)(3) that prepares BU pre-health students for volunteer roles at Brigham and Women's, Boston Medical Center and Tufts Medical Center. Getting a student from signup to their first shift runs through leadership approval, training, policy sign-offs and hospital clearance, and the hours they log afterwards are what the organization reports to grant funders, hospital partners and scholarship committees.

It needed all of that on both the web and a native phone app, plus an admin side for the board. The default path, a Next.js API tier in front of the database with a second client written against it, duplicates auth, pagination and upload logic across two codebases and doubles the surface where they can drift apart.

A four-stage access flow mirrors how the organization actually moves a volunteer into service: leadership approves the signup, the volunteer completes onboarding modules with policy sign-offs, hospital clearance codes unlock a site, and only then does hour tracking open up.

Volunteers check in and out of shifts or log hours manually, and every entry goes through admin review before it counts. Those approved totals are the numbers that get reported to funders, hospital partners and scholarship committees.

Messaging is real-time and Slack-style, with rooms created automatically from each volunteer's hospital clearances, so a student lands in the right channels the moment they are cleared. A portal feed carries announcements, events and opportunity sign-ups.

Board members get organization-wide dashboards and metrics, write posts and resources, and manage volunteers, sites and onboarding content from the same app.

Supabase is the backend, and Next.js is a client of it rather than a gateway to it. Both the web app and the React Native app talk to the same backend directly, with server-side code reserved for the few operations that genuinely need a secret.

That single decision is what keeps a second API tier from existing at all, and with it a second set of auth, pagination and upload code.

Authorization lives in the database, not in application code. It is a property every client inherits automatically rather than a convention a new screen can forget, and privileged multi-step operations are defined once and called identically by both clients.

Because of that, the database policy tests are the most important test suite in the project. A failing policy test is not a failing unit test, it is a data-exposure bug, and it is treated as one.

The shared data layer never imports a platform. Every function receives its client from whichever app is calling, so the same code runs unchanged on web and native.

The payoff is measurable: adding the entire native app required exactly one new file.

One Turborepo monorepo holds two apps and four shared packages: the Next.js web app with its volunteer portal and admin dashboard, and the Expo React Native app.

The shared packages split cleanly by responsibility: domain types and pure business logic with no I/O, the data-access layer, the database schema and its policy tests, and design tokens emitted as CSS for web and TypeScript for mobile.