UniBuzz

A private social network for university life — connecting students, clubs, events, campus news, housing, and the student marketplace in one place.

What UniBuzz is

UniBuzz is a social network for verified university students. Students connect with each other and with their campus: they post photos, videos and reels, talk anonymously in Buzz, follow each other, and message friends, groups and their classes. Each university is its own private community, where students mainly see their own campus's people, clubs, events, discussions and news.

It launches first at Texas State University (TXST), with plans to expand to campuses worldwide.

Mission: connect students, clubs, organizations and campus communities in one place, so university life is more social, more connected and more convenient.

Facebook began as a network for college students and then became a network for everyone. UniBuzz brings back that university-only feel. It isn't a general social network, and it isn't an apartment or marketplace app. It's the digital home of campus life.

The core: the social network

This is the product. New work, navigation and wording should start here.

Feature	What students get
Orbit	The personalized home feed (the For you feed): photos, videos, posts and reels from their campus.
Buzz	Anonymous campus talk in separate Campus and Global feeds, with polls, per-thread aliases, votes and replies, moderated by Trust & Safety.
Reels	TikTok-style short videos, full screen.
Profiles and following	University-verified identities with major, graduation year, bio and classes, followers, and privacy controls.
Messages	Private chats, group chats and automatic class group chats, with voice messages, replies and view-once Snaps.
Search	Find students to follow first, plus the listings on Explore.

Coming next, and part of the core:

• Clubs and organizations: pages to follow and join.
• Campus events: activities, club meetings, career fairs and hackathons.
• Campus news: university and student news.
• Calls: audio and video calls in any chat. They are built and paused behind a "Coming soon" label.

Supporting features: tools for campus life

These help with everyday student life and keep students in their community. They live together on the Explore tab and support the social network rather than define it.

Tool	What it does
Housing	Apartments and subleases near campus, including listings from local apartment communities.
Roommates	Posts from students who have a room to share or are looking for one.
Marketplace	Buy, sell, trade or give away furniture, electronics, textbooks, bikes and more.

Three connected platforms

1. UniBuzz: the social network for students, as an app for iOS and Android and a website.
2. UniBuzz Business: a portal at /business for local businesses, from apartment communities to restaurants, cafés, shops, startups and services. They post updates, products, deals and events and housing listings, run Sponsored ads in For You, Reels and Housing after the UniBuzz team's review, answer student inquiries (students always write first), read analytics and run a team with roles (Business v2, migrations 49 and 50).
3. CampConnect Admin: managing users, businesses, content and platform security. It covers the staff console at /admin on the website and the separate CampConnect Admin staff app (see Buzz (anonymous)).

Business model and design

The student platform is free. Revenue comes from businesses: advertising, promoted posts, paid listings and partnerships. Sponsored content is always labeled.

The design is modern, minimal and Apple-inspired, combining the best of Instagram, TikTok, Reddit and Discord.

Product direction for developers and AI assistants

• Social first. Lead with people, posts, Orbit, Buzz, Reels and messages. Housing, roommates and the marketplace are supporting tools, so don't let them set the app's identity, navigation or wording outside Explore.
• Campus first. Every feature belongs to a university community, and only verified students join, with a university email.
• Businesses stay off the social side. They can answer students who contact them but never start a conversation. "Sponsored" appears only on paid promotions, and "Verified Partner" only on businesses that have been checked.
• Legacy names. The product was called CampConnect until 2026-10-26 and is now UniBuzz; the separate staff app keeps the name CampConnect Admin. The project began as an apartment finder called "Apartment Book". That name survives only in identifiers: the package names (@apartment-book/shared), the app's slug, URL scheme and bundle ID (apartmentbook), the Vercel project and old migration comments. They're history, not direction. Don't rename them, because that would break builds, deep links and the database history.

Long-term vision

Become the main digital community for university students worldwide: one place to meet people, join clubs, find events and opportunities, follow campus news, and handle everyday student life, from housing to buying and selling.

Technology

Built with Next.js 16 + TypeScript + Tailwind for the website and Expo (React Native) for the iOS and Android app, on top of Supabase (Postgres, auth, realtime chat, image storage). The backend is a hosted service that the apps talk to directly, and all data-access code lives in a shared package, so the website and the app share everything except their screens.

How the app is organized

The layout follows the Facebook pattern: a top bar with three tabs (Home, Explore, Messages) plus the search box, a create menu and a profile menu; on phones the bar is Home, Explore, Messages, Profile at the bottom of the screen (the app's bar is Home, Explore, + (create), Messages, Profile, with Search and a Notifications bell that opens every notification in Home's top-right corner). Search finds people by name first (with a Follow button on every result), then apartments, roommates and items. Home itself has three top tabs, Orbit | Buzz | Reels (in the app under a UniBuzz wordmark, Instagram style; Posts is a fourth section that keeps its feed and its /?tab=posts address on the website but has no tab), see Home feed; the Explore tab holds Housing (apartments), Roommate and the Marketplace side by side, see Housing.

The sections below describe how each feature is built, the social network first and the Explore tools after it, then setup and deployment.

Feature map

Feature	How it is built
Home feed	Three swipeable tabs, Orbit first (Posts keeps its section and address without a tab). Posts and reels are feed_posts rows with likes, comments and saves; Buzz threads live in buzz_* tables that the API cannot read directly, only the buzz_* database functions can. The Orbit blend (posts and reels; Buzz stays on its own tab) is pure code in packages/shared/src/for-you.ts. See Home feed
Following	Follow people from their profile, like Instagram. Every profile shows follower / following counts to everyone, but who follows whom is private: on your own profile the counts open your Followers and Following lists, on anyone else's both open one list, Mutual friends (the people who are friends with both of you, by name), with a note that their followers and following are private; signed out, you are asked to log in instead. Home → Posts has a "Following" filter with only the posts of people you follow (in the app, a row of the feed dropdown in the Home top bar), and a notification tells you when someone starts following you; blocking someone ends the follow both ways. Migration 14 (supabase/migrations/20260923000000_follows.sql) adds the follows table and the follow_stats / following_posts functions; migration 21 (supabase/migrations/20261010000000_private_follow_lists.sql) lets only the two people in a follow read it (the counts come from follow_stats: the same totals for every viewer, whoever they have blocked, so a block cannot be used to find out whom someone follows) and adds the mutual_friends() function. The view each person gets and its wording live in packages/shared/src/profile.ts (followListView), the query in listMutualFriends
Profile	TikTok style, the same on the website (/profile/[id], /profile/me) and in the app (the Profile tab and /profile/[id]): the photo (yours with a "+" to change it), then three lines in this order: the full name, the major, class year and university ("CS ’28 @ Texas State University": profileStudyLine() and majorAbbreviation() in packages/shared/src/profile.ts, which shortens "Computer Science" to CS and keeps what was typed short already) and the bio; under them the @username with a QR button, Following · Followers · Likes (every like on their posts, reels and listings), Edit profile / Share profile / Find friends on your own profile and Follow / Message / ••• (block, report) on someone else's, then the tabs Posts, Classes, Reels, Saved, Liked and Listings over a three-column grid with view counts (in the app the tabs are icons with a sliding underline, and the open one carries a mark of who can see that section: a lock, two people or a globe). Listings holds their apartments, roommate posts and items for sale, each square with its kind and title (on the website the owner also sees the rented, sold or found ones, marked so). Every profile gets an @username made from the name, changed in Settings (unique; 3 to 30 letters, numbers, dots and underscores); people search matches it too. Classes are listed per semester (this one first, up to 12 each) with a section, the days and times it meets and the room; your own are added from two boxes, the subject and the course number ("CS" and "3358", kept as the one code "CS 3358" the database checks: and its checks in ), and the form closes once the class is in, a line by "Add class" saying so until the button brings the form back; in the app a hold on a class card offers Edit (the same form, filled in; ) and Delete, which asks first, while the website keeps its remove cross; listing a section puts you in its course chat, a group chat shared by everyone at your university taking that section that semester (the first classmate's listing creates it, removing the class leaves it, and a notification tells you about both). Who can see Classes, Saved, Liked and Listings is each person's choice of Everyone, Friends (people you follow who follow you back) or Only me, set from the line at the top of the tab or in Settings → Privacy; the defaults are Friends for Classes and Only me for Saved, Liked and Listings (migration 37), and a visitor without access (or anyone blocked either way) gets no tab for that section at all: no icon, no lock, and its address opens Posts. The owner always sees every tab. The listings themselves stay public in Explore; the setting covers the profile's Listings tab. Pin up to three of your posts or reels to the top of the grid from their ••• menu (in the app also by holding the square). Share profile, or the QR button, opens a sheet with the QR code of the profile's web address, Share and, on the website, Copy link. Migration 18 () adds and the three visibility columns, the table, (three pins at most, checked by trigger) and the , , , and functions; likes stop being readable row by row, so counts come from and the "Liked by" faces from , which honours each liker's Liked setting. The wording and helpers live in , the queries in

Photos: full quality, built to hook

Photos are the product, so the pipeline never degrades them:

• Originals are stored untouched. The browser uploads the exact file to Supabase Storage (JPG, PNG, WEBP, GIF or HEIC, up to 25 MB each, up to 12 per listing). Nothing is resized or re-encoded on upload.
• Sharp on every screen. Feeds and detail pages render through Next.js image optimization at quality 85 to 90 in AVIF/WebP with a size chosen for the viewer's screen (images.qualities, deviceSizes and formats in apps/web/next.config.ts). The full-screen viewer shows the original file itself, and its "Original" button opens it directly.
• No blank boxes. At upload time the browser reads each photo's dimensions and builds a tiny blurred preview (about 1 KB) that is saved as image_meta next to the listing. Feeds show the blur instantly and fade in the real photo, and layouts never jump.
• Instagram-style feed. Cards are photo-first with swipeable multi-photo carousels, a photo counter and dots, price overlaid on the photo, a bookmark button, and double-tap to save with a burst animation. Feeds load more as you scroll ("You're all caught up" at the end) and open with a stories-style strip: closest to campus on Home, fresh finds on Marketplace.
• Detail pages. Swipeable hero, thumbnail strip, and a full-screen viewer with swipe, arrow keys, double-tap zoom and the original download.
• Uploader. Drag and drop or pick files, instant previews while uploading, per-photo progress and errors, reorder, and "Make cover".

Vercel's Hobby plan optimizes up to 5,000 distinct source images per month. If the site outgrows that, upgrade the Vercel plan or move rendition generation to Supabase image transformations (Pro plan).

Notifications

A notifications table that only its recipient can read, mark or delete; rows are created by database triggers so the mobile app gets them for free: a new message (repeated messages in one chat refresh a single unread entry; it rides along for the push but shows only in Messages, see below), someone saved your listing, someone started following you (one entry per follower, however often they follow and unfollow), someone replied to your comment, someone sent you a Snap (one entry per chat until it is read, see Snaps), a call you missed (call, see Calls), and a new place pinned within 2 miles of your campus (opt-in per person in Settings). The top bar shows a bell with a live count and dropdown; /notifications lists everything except new messages and Snaps, which belong to Messages alone (its unread counts and badges, and the push): listNotifications() and getUnreadNotificationCount() in packages/shared/src/queries/notifications.ts leave out MESSAGE_NOTIFICATION_TYPES, and since migration 37 so does unread_notification_count(). Since migration 36 (supabase/migrations/20261029000000_push.sql) every notification notify() makes also goes to the person's phones: send_push() posts it with pg_net to Expo's push service, to the Expo push tokens the app stores in device_push_tokens (a real device, signed in, with permission granted), with the notification's type and link as data so a tap opens the right screen; nothing is sent where pg_net is missing, and a push that cannot be sent never fails what it rides on. With Expo's enhanced push security turned on, put the project's access token in Vault as expo_push_token and it goes along.

Snaps

A Snap is a photo or a video (up to 30 seconds) taken with the phone's own camera from the app's + menu (Post, Reel, Buzz (anonymous), Snap) and sent straight into the direct chats of the people you pick, each of whom can open it once. The camera opens over whatever is on screen; what it takes fills the screen on black (a photo over a blurred copy of itself) with close and "take another" at the top and the Aurora Send To at the bottom. Send To rises as a sheet with your direct chats (the most recent first) and your friends (people you follow who follow you back), and a search over them; pick up to 50 and the round send button shows the upload going up, then the paper plane flies off and a tick lands. Each person gets one message in your direct chat with them (the chat is made when there is none), the inbox reads "Sent a Snap", and a snap notification says "Sent you a Snap" (a muted chat stays quiet). A chat never shows a Snap's picture: it is a bubble at the Snap's own shape (the app draws it like a sent photo, the same size) showing only a tiny preview in its own colours (made on the phone when it is taken, from the photo or the video's first frame), softly visible under a light pane of frosted glass (colours and vague shapes, drifting slowly while the Snap waits to be opened, never a detail: the preview is 32 pixels on its long side), with "Tap to view" for its recipient and "Delivered" for its sender; tapping opens it full screen once (a photo until you tap, swipe it down or close it; a video plays through once with a bar along the top), and from then on both see "Opened" over the same blurred preview (in the app at seven tenths of the size): since migration 32 opening it leaves the preview on the message, while a Snap that goes unopened (it expires, or its sender's account goes) still loses it at once (migration 29). A Snap nobody opened within 31 days expires and both see "Expired". Under every Snap both sides see what happened to it, Snapchat style, with the time: delivered, opened, a screenshot or a screen recording (the sender is told at once with a snap_activity notification), all as the same quiet grey note, never a warning, deleted (the sender can take a waiting Snap back), expired; a tap opens the whole story, which stays after the Snap is over (messages.snap.activity, migration 33). The sender is never told more than the viewing phone can detect: an iPhone reports screenshots and blacks out recordings, an Android phone blocks both, and anything else reports that it can detect nothing. The website shows the same cards and says to open the app to view one.

The database enforces all of it (migration 28, supabase/migrations/20261020120000_snaps.sql). The files live in a private snaps bucket that no client can list, replace or delete: the sender uploads into their own folder, and a recipient can read a file only from opening it until they close it, two minutes at most (open_snap() / close_snap()), never after it expired and never twice; the app loads it through Storage's signed-in download with the viewer's own session, so every request is checked against that and no link outlives the view. The snaps, snap_recipients and snap_purges tables have no policies and no grants, and messages.snap is written only by send_snap() and open_snap() (a trigger refuses it from the API). send_snap() takes only friends and people you already have a direct chat with, nobody blocked either way. Every 10 minutes purge_snaps() (pg_cron) forgets every Snap that everyone has opened (10 minutes on), every Snap that expired and every file uploaded but never sent (an hour on), and deletes the files through the Storage API with pg_net, using the project URL and service key that npm run db:setup keeps in Vault; a file is checked off only once Storage no longer has it, and a chat whose Snap went unopened (it expired, or its sender's account was deleted) is told at once. The moment the last person a Snap went to closes it, close_snap() deletes its file itself (migration 30) rather than waiting for the purge. One thing the database cannot close: Supabase's CDN keeps serving a file it has handed out to the same person, under any of their sessions, for about a minute after the file is deleted (and until then for as long as it exists, whatever the policies say by now); nobody else can get it that way (the CDN checks who is asking; this was measured live on 2026-10-23). So with a tampered app the recipient who just watched a Snap could fetch the same bytes once more for up to a minute, and no one else ever can. The app keeps a viewed photo in memory only, never on disk.

Stories

A story is one photo or video shared for 24 hours, Instagram's way. In the app, a row of rings sits under Home's Orbit | Buzz | Reels tabs, at the top of Orbit: Your story first (your photo with a +; once you have one, your ring, which opens it), then everyone whose stories you may see, those with something unseen first in the aurora ring, the rest in grey. A tap opens them full screen: a photo for five seconds, a video for its length (60 seconds at most), a bar for each along the top; tap right to go on, left to go back, hold to pause, swipe sideways to the next person, pull down to close. Your own stories show how many people have seen each, a tap on which lists them, and a bin to take one down. A story is shared from the publish screen of the + create flow: Your story beside Post, with the post's own audience choice (Texas State, Global, Friends or Selected people) and editing tools; each photo and video becomes a story. The website shows no stories yet.

Migration 58 (supabase/migrations/20261110000100_stories.sql) keeps every rule on the server: stories with a restrictive select policy that applies migration 44's audience rule (can_see_story(): campus by the verified email domain, friends both ways, story_viewers for selected people, written by set_story_viewers()), the expiry and blocks; a trigger stamps the author, the time and the 24 hours whatever the client sent; only the author deletes, nothing updates; story_views, written by mark_story_seen() alone (once per viewer, never the author's own, never for a story the viewer may not see), read in full by the author and one's own rows by a viewer; stories_sweep() deletes stories a day past their expiry (pg_cron hourly). supabase/tests/stories.test.mjs runs all of it in PGlite; packages/shared/tests/stories.test.mjs the tray's order and the viewer's timing.

Calls

Paused for now. Until there is an Apple Developer Program membership no iPhone build can carry calls, so the app keeps every call button, call row and call screen but a tap shows a quiet "Coming Soon" notice under the chat's bar instead of ringing anyone: nothing is written to the database, no ring is listened for, and the Join banner stays hidden (CALLS_PAUSED in apps/mobile/src/lib/calls.ts). Everything below stays in place, deployed and tested (the database, the livekit-token function and its LiveKit secrets, the native modules and their config); a build bundled with EXPO_PUBLIC_CALLS_ENABLED=1 turns calls back on. The rest of the app runs in Expo Go.

Audio and video calls, FaceTime style, in every chat: a direct chat rings one person, a group (a class group too) rings everyone in it, and anyone can join a call that is going on. The chat's top bar has Audio call and Video call beside Info; a call opens on its own dark stage with the other person's video (or their photo) filling the screen and your own camera in a small window, a grid for a group (the people it is still ringing faded, "ringing" under their names), their name and the call's standing at the top ("Calling…", "Connecting…", the running time) and a glass bar of controls along the bottom: mute, speaker, camera on and off, flip camera, the people in the call (a group), and the red End button. The caller hears a ringback; the phone being called rings and buzzes (respecting the silent switch) and shows a full-screen incoming call with the caller's photo and Decline / Accept over whatever is on screen; a ring that nobody answers within 45 seconds stops on its own and the call is missed. Every call is a row in the chat, the same on both sides and on the website, that follows the call live and reads, once it is over, "Audio call · 3:24", "No answer" (for the caller), "Missed video call" (for whoever did not pick up, in red, with a call notification), "Video call declined"; a tap on it calls back, or joins the call if it is still going on, and a glass pill under the chat's bar offers to Join a call going on in the chat that you are not in. Leaving the call screen in any way hangs up; when everyone else has left, yours ends too.

The database keeps every call and who stands where in it (migration 35, supabase/migrations/20261028000000_calls.sql): the calls and call_participants tables, readable only by the chat's members, written only through start_call(), answer_call(), decline_call() and leave_call() (get_call() and current_call() read them with the participants' names and photos); messages.call, the call's row in the chat, is written only by those functions (a trigger refuses it from the API) and updated as the call goes on, so the chats and the inbox preview follow it live over the existing realtime channel; a ring that was never answered is closed as missed by the next call anyone makes (expire_stale_calls(), 60 seconds on), and an active call left hanging is closed after 6 hours; the call's own message sends no "new message" notification, and only a missed call sends one (call, deduplicated per call). supabase/tests/calls.test.mjs runs all of it in PGlite (ringing, answering, declining, cancelling, the ring running out, a group where some decline and some join late, strangers and the API refused, the row's text on both sides); packages/shared/tests/calls.test.mjs the row's wording.

The sound and picture travel over LiveKit (WebRTC, end-to-end over DTLS-SRTP), one room per call named by the call's id. The livekit-token Edge Function (supabase/functions/livekit-token/index.ts) checks the caller's session, asks the database with get_call() that they are in the call (state joined) and mints a two-hour token for that room alone; without a token nobody connects, so the chat's membership rules are the call's. To set it up: make a LiveKit Cloud project (free tier at cloud.livekit.io; or run a LiveKit server), then npx -y supabase@latest secrets set --project-ref dskbzoqreandwwpxiplh LIVEKIT_URL=wss://… LIVEKIT_API_KEY=… LIVEKIT_API_SECRET=… with SUPABASE_ACCESS_TOKEN set (the function itself is deployed with npx -y supabase@latest functions deploy livekit-token --project-ref dskbzoqreandwwpxiplh, no Docker needed; the Dashboard's Edge Functions page takes the same file). Until the secrets are set the function answers "Calls aren't set up on the server yet." and the call screen says so. SUPABASE_ACCESS_TOKEN=sbp_… node apps/mobile/e2e/call-lifecycle.mjs runs the whole signalling lifecycle against the live project with throwaway accounts, asks the function to check its key pair against LiveKit ({"check": true} answers whether LiveKit accepted a server token, never a secret) and reports whether a call token can be minted, leaving nothing behind. The apps' media module (@livekit/react-native, @livekit/react-native-webrtc, with their Expo config plugins in app.json: microphone and camera permission texts, background audio, Android's communication audio mode and Bluetooth permissions; the camera text is written twice, as ios.infoPlist.NSCameraUsageDescription and as expo-image-picker's cameraPermission, and the plugin's is the one iOS shows, so the two stay the same: video calls, taking photos and recording videos) is compiled only into the app's own builds, never into Expo Go: in Expo Go calls still ring, answer and show their rows, but no sound or picture flows, and the call screen says the build cannot carry calls. Ringing reaches a phone over realtime while the app is open (and any ring still waiting is picked up when the app comes back to the front, within the 45 seconds); a phone whose app is in the background or closed is rung by a push (migration 36: start_call() sends "Incoming video call · Maya is calling" to everyone it rings, with the app's own ring sound on the Calls channel, dropped unseen once the 45 seconds are over), and tapping it opens the incoming call in the app if it is still ringing. That is a notification, not a system call screen: the full-screen native ring of a locked phone (iOS CallKit with PushKit, Android's full-screen intent) is not built, and would need an Apple Developer account's VoIP certificate. In a call, an iPhone keeps the sound going in the background () and pauses the camera, as every app's does; an Android phone keeps it only as long as the system lets a backgrounded app use the microphone (newer versions cut it after a while without a foreground service, which is not built either). A refused microphone or camera does not end the call: the screen says to allow it in Settings.

Home feed

Home has three tabs in TikTok's layout, left to right: Orbit | Buzz | Reels; Posts is a section without a tab (HIDDEN_HOME_SECTIONS): its feed, its /?tab=posts address and every post feature stay, and Orbit keeps blending posts (and reels) in. They are swipeable: in the app the three pages sit side by side in a pager, and on the website a sideways touch swipe across the section body moves to the neighbouring tab (touch screens only; a multi-photo carousel keeps its own swipes). In the app the floating top bar over the feed has two rows, like X's: your photo in a teal-to-violet ring on the left, which opens your profile, the UniBuzz wordmark (HOME_BRAND) in the middle (it reads "Following" while that feed shows), and Search and the Notifications bell on the right (Search opens the people search; the bell opens the notifications screen and its badge counts the unread); then the three labels spread across the second row, highlighted like X: the active one bold with a rounded violet underline as wide as the label, sliding with the finger over a hairline across the whole bar; moving between sections, by tap or swipe, plays no haptic. Under the labels sits a Campus | Global toggle, a small segmented pill whose thumb slides to the choice: Campus is your own university, Global every university (Following joins it only while Posts has a tab: it keeps Posts to the people you follow and moves to Posts); the row is not drawn for someone without a university. For now the toggle is hidden everywhere, under the labels and in the full-screen viewer (SCOPE_TOGGLE_SHOWN in apps/mobile/src/lib/home-scope.ts is false): the bar is just its first two rows and every feed stays on your own campus; the toggle's code is all kept, and setting the flag back to true brings it back. The bottom bar reads Home, Explore, Messages, Events, Profile, with no "+": in the app creating starts from the floating "+" at the bottom right of the feed (X's compose button; Buzz has its pen there) and Upload in the menu under your photo, and Home's top bar has no "+", over Reels included. The bar scrolls like Instagram's: it slides up out of the way as the page on screen scrolls down and back the moment the page scrolls up, however far down it is (a swipe or a tap between pages brings it back too; Reels never moves it). Explore's Housing | Roommate | Marketplace row and the pills under it (the Marketplace's categories among them) do the same under its fixed top bar. The bottom bar floats over the content as a rounded glass pill (real liquid glass on iOS 26, a translucent fill elsewhere), and every tab keeps room clear under it; while a page of Home (For you, Buzz), Explore or Events scrolls on it collapses like Reddit's to a circle holding that tab's icon (Home's, Explore's or Events'), the other tabs fading, the "+" becoming the same circle opposite it, and it returns whole as soon as the page scrolls back (apps/mobile/src/lib/tab-bar-collapse.ts). The campus and the Following choice live only in that menu (, shared by Orbit, Buzz, Posts and Reels): the pages have no filter chips of their own. Orbit is the landing tab and keeps the clean address, the others live at , and . The order and the addresses come from and in , so the website and the app always agree.

Tab	What it shows
Orbit	Posts and reels blended into one feed; anonymous Buzz threads are never part of it, they live only on the Buzz tab. blendForYou in packages/shared/src/for-you.ts spreads the reels between the posts in a fixed pattern (post, post, reel, post, post, post, reel, post), each kind keeping its own order (newest first), so a page looks the same on every device and every reload. Each kind is paged on its own (FOR_YOU_PAGE: 6 posts and 2 reels per page), so page two never repeats page one; a kind that runs short is skipped and the other fills in. Works signed out
Buzz	UniVerse's anonymous campus feed, ported whole: Campus and Global as separate feeds, per-thread emoji aliases ("☄️ Anon Comet"), Hot / New / Top, search, polls, photos or one video, each card's top reply, replies threaded like Reddit's (two levels on the website) and My buzzes, in the dark "Phosphor" look. Every buzz and reply passes the moderation engine before it is stored, and the buzz_* tables cannot be read through the API at all: only the buzz_v2_* database functions decide what leaves the database. See Buzz (anonymous)
Posts	Photo-first rows (in the app every post, roommate post and apartment shares one layout: avatar, name and " · Oct 2" up top, the words next, folded to three lines with "more…" / "less" (a roommate post's description stays hidden whole behind "more…"), then the photo in a rounded frame inset from the screen edges, no card box) with swipeable carousels (the slide dots on their own row under the photo), heart / comment / share / bookmark (the heart pops when tapped and a double tap on the photo likes with a big heart burst; in the app the like also buzzes the phone through expo-haptics), "Liked by …", a caption with hashtags, the newest comment and, behind the comment icon, the thread itself, TikTok style: "N comments" with a Top / Newest sort, a heart with its count on every comment (a dislike stays private), Reply, replies folded behind "View N replies", and a hold on a comment for Reply / Report / Block / Delete
Reels	Vertical full-screen video (reels and apartment video tours), one at a time, autoplay with a shared sound button; the heart in the side rail and a double tap on the video like it with the same heart burst (and buzz in the app), the comment icon opens the same thread in a drawer

Checks for the Home feed:

Check	How
The Orbit blend, the Home and Housing tab order and addresses, the snapshot a shared post carries into a chat (packages/shared/tests/share.test.mjs) and the profile helpers (packages/shared/tests/profile.test.mjs: semesters and classes grouped by term, class codes and usernames checked like the database checks them, the who-can-see wording, which follower list a viewer gets and its wording, grid squares) and calls (packages/shared/tests/calls.test.mjs: the call read from a message, durations, the inbox preview and the row's text on each side) and activity status (packages/shared/tests/activity.test.mjs: "Active 1 min ago" to "Active 2 days ago", "yesterday" by the calendar (also the nights the clocks change), never "0 min", a few minutes of clock skew, nothing before presence is known or without anything to show, "Active now" only with a recent stamp (and with no time for someone who has not written to you); the presence store on its private channel, with its readiness, appearing only while a fresh stamp is in, the grace before a tab stops appearing and leaving at once on a phone, coming back (no re-appearing after a hide made elsewhere), Realtime's presence-call limit, the minute heartbeat and block list, a status hidden on another device, a refused join, a session that ended and one only being renewed, rejoining after a close, a dropped connection short or long, people blocked either way; activity_status asked in batches of 100) (unit tests, no network, Node 22.18+)	npm run test:shared
Migrations, row-level security, Buzz v2 (supabase/tests/buzz-v2.test.mjs) and Trust & Safety (supabase/tests/trust-safety.test.mjs, see Buzz (anonymous)), following (supabase/tests/follows.test.mjs: the follows policies, follow_stats, following_posts, the follow notification, blocking, account deletion) and comment threads (supabase/tests/comment-threads.test.mjs: replies and their parent checks, post_comment_vote() and the score, the reply notification, deletion with its replies, blocking) and comment likes (supabase/tests/comment-likes.test.mjs: the hearts count only the likes, a dislike stays private, the counts belong to the server) and shared posts (supabase/tests/shared-posts.test.mjs: friends are mutual follows minus blocks, a share without words, the "Sent a post" / "Sent a reel" previews and notifications, plain messages unchanged) and the profile page (: usernames, the who-can-see settings and their defaults, classes per semester, the Saved and Liked lists behind those settings with like counts unchanged, blocking, profile numbers, view counts, at most three pins) and private follower lists (: a follow readable only by the two people in it, the owner reading all of theirs, giving every viewer the same totals whoever they have blocked (zeros only across a block with that profile), mutual friends (exactly the friends both have, by name; nothing signed out, on your own profile or across a block), closed to the API while friends-only sections still open, and , , following, its notification and blocking unchanged) and activity status (: closed to the API signed in and out, heartbeats that stamp only people who show their status ( from old builds too) and leave no trace on , not even a lock, ' and ' system columns closed to the API (an anonymous Buzz reply can no longer be matched to its author or dated), the grant following whatever columns each table has, hiding deleting the time and stopping "Delivered", showing it again only through (a stale save cannot), moving only for something new (a message sent dated ahead is dated when it was sent, so it cannot keep "Seen" or "Delivered" moving), chat members changing only their receipts and a group's name (even with no filter), a scheduled notification out of reach of filterless updates and deletes, rule by rule (hide yours and you see nobody's, someone hiding theirs, blocked either way, no shared chat, an empty chat or a group nobody wrote in giving "recent" with no time, what a group said before you joined, leaving a group, cut to the minute, recent, 100 ids at most, refused signed out), , emptied for good, and the presence policies against a stand-in realtime schema) and Snaps (: the private bucket and its upload rules, who a Snap can go to, every check in , one message, preview and notification per person and none in a muted chat, the one view with its two minutes and , expiry, blocking, a sender's account going, and against stand-ins for pg_net and Vault) and calls (, see ) and push (: every notification pushed once per device, the ring push with its channel, sound and 45-second life, a muted chat quiet, no tokens no request, the Vault access token, the API refused), offline in PGlite

Buzz (anonymous)

Buzz is UniVerse's Buzz, ported whole into the app and the website: the same feeds, aliases, rules, moderation and look, running on Supabase instead of UniVerse's Express + SQLite server.

Piece	Where
Buzz database: tables, aliases, the serializer, every read and interaction	migration 42, supabase/migrations/20261103000100_buzz_v2.sql
Trust & Safety: reports, the moderation queue, sanctions, appeals, the audit log, the staff console's functions	migration 41, supabase/migrations/20261103000000_trust_safety.sql
Moderation engine: rule packs, the private-info detector, policy, what the writer is told	packages/moderation (server only, never bundled into the app)
Write API for new buzzes and replies	apps/web/src/app/api/buzz/**, apps/web/src/lib/buzz-server/**
Types, copy, limits, helpers and the client calls both apps use	packages/shared/src/buzz/**, packages/shared/src/trust-safety
Screens	website apps/web/src/components/buzz/** and /buzz/*; app apps/mobile/src/components/buzz/** and src/app/buzz/*
Staff console	website only, /admin (apps/web/src/app/(app)/admin/**)

What it does:

• Two separate feeds, Campus and Global. A buzz goes to exactly one of them. Hot, New and Top (Today, This week, All time), plus search.
• Posts. A buzz has an optional title (up to 100 characters) and text up to 500. It can carry up to 4 photos or one video of up to 60 seconds, or a poll. Polls have 2–4 options and run 1, 3 or 7 days. Their results stay hidden until you vote, and they unlock 24 hours after joining.
• Aliases. Everyone in a thread gets an emoji alias for that thread, such as "☄️ Anon Comet", with the original poster marked OP. The alias comes from a secret salted hash of the thread and the author, so the same person has a different alias in every thread.
• The gate. Before their first read, everyone accepts the Buzz guidelines. To ask everyone again, bump BUZZ_GUIDELINES_VERSION (packages/shared/src/buzz/constants.ts) together with public.buzz_guidelines_version().
• Campus extras:
  • a daily Campus Prompt;
  • a campus with no buzzes yet shows Global (cold start);
  • campuses under 50 students get a "small campus" note in the composer and are never named next to a buzz.
• Votes. Up and down. A buzz or reply collapses at a score of −5 or less with at least 8 eligible votes. It is hidden for review at −10 or less with at least 12. Eligible votes come from accounts older than 24 hours that aren't muted. Authors get milestone notifications at 10, 25, 50, 100 and 250.
• Replies. In the app, a tree like Reddit's: each reply under the one it answers at any depth, with thread lines, Best / New / Old, folding, "N more replies", "Continue this thread" and a dot on replies new since your last visit (treeParentId, migration 20261108000000_buzz_reply_tree.sql). The website, and the app on a database without that migration, show two levels; deeper replies are flattened and show who they are replying to.
• Daily prompt. Each day's prompt has one thread per campus and one on Global, owned by no one and titled with the prompt; answers go into it as replies by default, or as a buzz of their own, which always carries the prompt as its title and links to the prompt's thread. Migration 20261108000200_buzz_prompt_threads.sql; the app shows it, the website shows prompt threads as ordinary buzzes for now.
• Categories. Posting a buzz, its author may pick one category (Confessions, Questions, Hot takes, Rants, Dating, Classes, Funny, Events, Housing, Careers), or none; cards and threads show it under the alias line. Nothing filters by it yet. The list is BUZZ_CATEGORIES (packages/shared/src/buzz/constants.ts), and the database refuses anything else; to change it, change both (migration has the database's copy; checks they agree).

The anonymity firewall:

• Closed tables. The buzz_* tables cannot be read through the API. Every read goes through buzz_v2_* functions that build the outgoing JSON field by field, in one serializer. It sends aliases, never an author id, name or photo, and cuts times to the minute. Only the client functions are callable; every internal helper (the alias book, the author lookup) is revoked from every API role.

• Jitter. New threads publish 0–3 minutes late and replies 0–45 seconds late, so a buzz can't be timed against someone's activity. For the same reason Buzz has no realtime; the screens refresh every 30 seconds.

• Held items. Something held or hidden for review is shown only to its author. "Not found" looks the same whether an item doesn't exist, is held, or is someone else's.

• Notifications about Buzz never carry who acted or anything that identifies them. A reply notification quotes your own buzz, never the reply.

• Media. Photos are stored under uploads/buzz/anon/<random> with location and camera details removed, and that folder cannot be listed. Videos go through Mux with nothing linking them to the uploader.

• Blind moderators. The staff console shows content, never authors, and nothing a moderator does to a buzz shows on anyone's account page. Only an admin can unmask an author, and it takes:

  • a reason code;
  • a written reason of at least 30 characters;
  • the typed word UNMASK.

  The audit row is written before anything is revealed, the other admins are notified, and the identity masks again after 5 minutes. Admins are limited to 10 unmasks a day.

Moderation and Trust & Safety:

• The write API. Every new buzz and reply goes through the website's write API (POST /api/buzz, POST /api/buzz/<thread>/replies), which runs the moderation engine before anything is stored. The database accepts Buzz writes only from that server (service-role functions), so neither the app nor a script can skip moderation. Blocked text gets an explanation linking the Community Guidelines (/guidelines). Self-harm gets support resources as well.

• Optional AI second pass. With MODERATION_AI_API_KEY set, the server asks Claude (claude-opus-5-5) to re-check what the rules allowed, after the response has gone out. It can only escalate (flag for review). It never allows something the rules blocked.

• Reports and sanctions. Reports (12 reasons) go to the staff queue. Sanctions (warning, mute, suspension, ban) show on Settings → Account status, where the person can appeal once, within 14 days. A different staff member from the one who acted reviews the appeal.

• Sanctions outside Buzz. As in UniVerse, sanctions also hold outside Buzz:

  • a mute, a suspension, a ban or an unacknowledged warning refuses new posts, reels, comments, listings and roommate posts at the database;
  • suspended and banned accounts cannot send messages, but muted people can still answer in their chats.

  A suspended or banned account can still sign in and read, because UniBuzz has no restricted session. The console lists this and its other differences from UniVerse under Limitations.

• The staff console (/admin, website only) has Queue, Users, Appeals, Audit, Metrics and Rules. Everyone who isn't staff gets a plain 404 there. Staff confirm it's them with an authenticator app first (/two-factor, two-factor sign-in): the database refuses every console function without it.

• With CampConnect Admin. Production also runs CampConnect Admin, the separate staff app whose migrations reached the live project from outside this repo (supabase/applied-outside-repo/README.md). Where its tables exist the two work as one:

  • its staff list is the console's: owners and admins are admins, moderators are moderators, and staff are added and removed there, never in the console;
  • its two-factor rule is the console's, with the same authenticator app (it's the same account);
  • hiding a buzz or reply there removes it on Buzz (out of every feed, a placeholder in its thread, still its author's), and restoring it brings it back; a removal or an auto-hide on Buzz shows in its hidden list;

Setting it up:

1. Apply migrations 41 and 42. They are not on the live project yet. Don't use npm run db:setup with an access token for this: that mode also rewrites the auth Site URL. Use its database-URL mode (SUPABASE_DB_URL=… npm run db:setup), or run the two files in order in the SQL editor and record each in public._migrations. First check that the live project matches this repo plus the outside migrations: SUPABASE_ACCESS_TOKEN=… node supabase/applied-outside-repo/verify.mjs --live --except 20261103000000_trust_safety.sql,20261103000100_buzz_v2.sql. Once migration 42 is live, the old Buzz functions (buzz_feed, buzz_get, buzz_create, …) answer "update the app", so redeploy the website and publish the app update right after (cd apps/mobile && npx eas-cli@latest update --channel preview). Existing threads and replies are converted and kept: threads without a campus become Global.
2. Give the website's server the service-role key. Set SUPABASE_SERVICE_ROLE_KEY=… in apps/web/.env.local and in Vercel (Production and Preview). Never make it a NEXT_PUBLIC_ variable. Without it, reading Buzz works but posting answers that Buzz isn't set up (503).
3. Staff. On the live project, staff are CampConnect Admin's: an owner invites people there, and they use the console once they've set up two-factor sign-in. On a database without CampConnect Admin, run insert into public.staff_members (user_id, role) values ('<your user id>', 'admin'); in the SQL editor (your user id is under Authentication → Users; moderators get 'moderator').
4. Optional: set MODERATION_AI_API_KEY for the AI second pass.
5. The app posts through the website. Its EXPO_PUBLIC_SITE_URL (apps/mobile/.env, default the live Vercel site) must point at a deployment that has this code and the service-role key.
6. Without pg_cron (Database → Extensions), run select public.buzz_v2_housekeeping() every few minutes another way. It closes due polls, tells their authors, and clears old rate-limit rows.

On a development server, /?tab=buzz&buzzFixtures=1 shows every Buzz screen with sample data, and so do /buzz/search?buzzFixtures=1 and /buzz/mine?buzzFixtures=1. Other variants: gate, muted, new, small, empty, error, blocked, held, support. Production builds leave the switch out.

Tests:

• npm run test:moderation: the engine, 422 tests.
• npm run test:shared: the helpers.
• npm run db:test: includes trust-safety.test.mjs and buzz-v2.test.mjs, offline in PGlite.
• scripts/e2e-home-feed.mjs: checks Buzz v2 on a live project once the migrations are applied.

Known limits:

• With every rule pack on, the admin.spam pack flags some ordinary phrases, such as "do i have to pay upfront for housing". Staff can turn that pack off under Rules.
• Storage sends a photo's upload time with the file (Last-Modified), so a photo buzz can be dated to the second despite the publication delay. UniVerse's uploads behave the same. Serving Buzz photos through the website without that header would close it.

Housing

Housing is one main tab, labelled Explore in the bar with a compass icon, with two halves, left to right: Housing | Roommate (apartments and roommates), and the Marketplace as a third page right after them (its grid, hearts, category pills, search and "Sell an item" moved in unchanged). Like the Home tabs they are slidable: in the app the three feeds sit side by side in a pager under the tab's own bar, laid out like the inbox's ("Find", the labels with the sliding underline, the inbox's search box searching the page on screen with a round filter button beside it (a sheet of the page's own filters: sort, bedrooms, rent, distance from campus, furnished, pets and video tours for rooms; budget, who the post is open to, distance and video for roommate posts; sort, condition and price for items), then the pills: All, All | Has a room | Looking for a room, or All and the item categories) (tap a label or swipe; no haptic, like Home's), and on the website a sticky Housing | Roommate | Marketplace bar sits under the navbar and a sideways touch swipe across the page moves to the neighbouring section (touch screens only; the photo rail, the map and a multi-photo carousel keep their own swipes). Housing is the landing half. The website keeps the /apartments, /roommates and /marketplace addresses, so listing links, filters and the ?university= query are unchanged; the Explore tab in the navbar links to /apartments and stays highlighted on both. In the app the floating "+" follows the visible half: "List an apartment" on Apartments, "Create roommate post" on Roommates, "Sell an item" on Marketplace. The order and the addresses come from HOUSING_SECTIONS, DEFAULT_HOUSING_SECTION and housingSectionHref in packages/shared/src/constants.ts, so the website and the app always agree.

Events

Events is the fourth tab, with a calendar icon. It shows the campus's events in one place and lets people save them, share them, register and follow the organizations behind them. Two pages sit under the title, For you | All events, with the inbox's search box and one row of pills under them: the date pills (Upcoming, Today, This week, Weekend) and the category pills (Academic, Career, Social, Sports, Music, Arts, Tech, Wellness, Cultural, Service, Faith, Other). Every time is shown on the campus's own clock (universities.timezone).

Where events come from. Two sources only, so nobody can fill a campus's calendar on their own:

• The university's calendars. Staff add ICS or RSS feeds in the console (/admin/events, admins add and change feeds, every staff member can press Sync now). The website syncs them (apps/web/src/lib/events-server/sync.ts, called by /api/events/sync from Vercel Cron, daily on the Hobby plan, and by the console): it reads the calendar (packages/shared/src/events/ics.ts, rss.ts: folded lines, local and UTC times, all-day events, weekly and monthly rules, overrides, cancellations), plans the difference against what the database has (events/sync.ts: new rows, changed columns, future events the feed dropped marked cancelled, never deleted), skips an event another feed or an organization already lists (same title at the same moment on the same campus), guesses a category from the calendar's own words, and writes with the service role. A feed's event a staff member hid stays hidden through later syncs.
• Organizations. Any student can create a club, student organization or department and becomes its owner; owners add editors and other owners. Members publish and manage its events in the app. Until staff verify the organization (the console's Organizations section), its events are pending: its members see them, nobody else does. Verifying publishes them; unverifying or hiding the organization takes them back.

What people do. Save (the bookmark; /events/saved), share (the native share sheet with the website's address), open the registration link, follow an organization, pick interests. Each of those feeds the ranking below. Opens, registration taps and shares are counted once a day per person (record_event_click()); only the counts leave the database, and a student reads only their own rows.

For you. One formula in code (rankEvents, packages/shared/src/events.ts), the same in the app and on the website, deterministic: a picked interest (+3), the categories the person keeps saving and opening (up to +2.5), a followed organization (+4), how soon it is (+3 tonight, half of that in a week), how many others saved or opened it, a picture, a verified organization; a cancellation counts against. Among the first five rows one organization does not take a third row in a row while something else scores within a point. The pills always apply on top. Signed out, time and popularity alone.

Staff. /admin/events in the Trust & Safety console: the counts, the feeds (status of the last sync, its error, Sync now, add, edit, delete), the organizations (verify, unverify, hide, restore, with a note) and the events (hide, cancel, restore, with filters). Every change is an audit_log row (organization.verify, event.hidden, event_feed.create …) written in the same transaction by the events_console_* functions, which answer non-staff "not found" and need two-factor sign-in like the rest of the console.

Multi-campus. Every event, feed and organization belongs to a university; every university has a time zone; the Events tab shows the signed-in student's campus (everything, signed out). A new campus is a seed row with its zone.

Business portal

UniBuzz Business is a website of its own for landlords and local businesses, served at /business on the main site, and at its own domain once one is set (NEXT_PUBLIC_BUSINESS_SITE_URL; none yet). It has its own login and sign-up but shares the backend and the auth with the student apps; there is no mobile app for it, and the student app shows a business account only a notice pointing to the portal.

• Roles. profiles.role is student (everyone so far), business_owner, business_staff or admin (migration 39, supabase/migrations/20261101000000_business_portal.sql). Nobody can change their own role: a trigger keeps it, and only the sign-up trigger and grant_role() (database owner only) set it. Make someone an admin from the SQL editor with select public.grant_role('<profile id>', 'admin');. On the live project, staff owners and admins from the admin section become admins here too.
• Signing up and review. A business signs up with any email address (students still need a university one) and starts as a pending business. The UniBuzz team approves, rejects or suspends it on the portal's Review page (admins only); approval waits until the owner has confirmed their email.
• Standing decides access, on every request. Pending: the profile, deal drafts and the team; nothing students see, no listings, no inquiries. Approved: everything below. Rejected: the owner may fix the profile; nothing else. Suspended: nothing. The listings are archived and hidden from students whatever their status says, the deals are paused, and the team's sessions immediately lose the chats (live message events stop too), the listings, deals, numbers and uploads; the portal shows only the suspension. Students keep their chat history with a suspended business but can't write to it.
• Labels. "Verified Partner" only for a business an admin verified, with what was checked on record (admin_set_verified(); the database refuses the mark without it, and anything but approval clears it). "Sponsored" only for a listing or deal with a paid promotion running now: an admin records it on the Review page once it is paid, with the period, the amount and the invoice or receipt reference (admin_record_promotion(); nothing else can create one, and payment itself happens outside UniBuzz). Students read the labels through the listing_sponsored and deal_sponsored computed fields; a business that is neither shows a plain "Business".
• Listings. Apartments posted from the portal are ordinary apartments rows with business_id set, owned by the business's owner whoever on the team posts them. They appear in Explore › Housing in the app and on the website with the business's name and logo, its label and no student profile behind them.
• Deals. Offers with campus targeting (the universities whose students see them; none ticked means every campus), a start, an optional end and an optional code. Students see live deals of approved businesses on the website's page, reached from a link on the Housing page when any exist.

UniBuzz Business v2 (migrations 49 and 50)

Built on the v1 rules above, which all still hold (business-portal.test.mjs runs them on the new schema).

• The portal's sidebar (components/business/portal-sidebar.tsx). The business's name and photo at the top open its public profile preview. Graphite, with Overview, Inbox, Advertisements, Products & Services, Analytics and Billing in that order, and Settings apart at the bottom above the account menu (appearance, log out). portalSectionsFor() decides what a member sees: an analyst has no Inbox, an editor no Billing, a pending business an Inbox that says it opens on approval, a rejected one Overview and Settings. On tablets and phones it is a drawer behind the top bar's menu button.

  • Overview: active ads, the month's spending and the inquiries waiting for a reply, then the last 30 days.
  • Inbox (owner, admins, editors; inbox/layout.tsx, components/business/inquiry-list.tsx), Instagram style:
    • each row is the student's photo and name, the newest message ("You:" or a teammate's first name when the team wrote it), what the chat is about (a listing, a post, an ad or the profile) and an unread count, or a dot when the student wrote last;
    • filters (All, Unread, Needs reply, and Listings, Posts, Ads or Profile when there are any), a search over names, messages and what was asked about, and "Mark all read";
    • a chat opens with what the student asked about at its top (inquiry-context.tsx: the listing, post or ad as it is now, with its photo and price, linked to its page in the portal);
    • everything is live: new messages and receipts move the list, arrive in the open chat, and a reply shows at once;
    • on every portal page a new message shows a toast with Reply (not for the chat already on screen), raises the Inbox's badge and puts the count in the tab's title (message-alerts.tsx). Desktop notifications are off until turned on in Settings › Account or with the bell in the Inbox, per browser.
    • Students always start: the database refuses a business's chat, and any business message before the student's first. The Inbox lists, and opens, only chats a student has written in (migration 56 also hides the rest in the database). The inquiry helpers (inquiryKindOf, inquiryNeedsReply, INQUIRY_FILTERS, inquiryMatches) are in packages/shared/src/business.ts; getInquiryDetails() reads what each chat is about and who wrote last.
  • Products & Services: the posts, with a type filter (products, services, special offers, events, updates), and, for housing businesses, the listings.
  • Billing (owner, admins, analysts): the payments the UniBuzz team recorded, totals for the month, 30 days and all time, a CSV for the books, and a printable receipt for each payment. Nothing is charged from the portal.

Checks for v2: supabase/tests/business-teams.test.mjs, business-ads.test.mjs, media-server-fields.test.mjs, business-hardening.test.mjs and production-rollout.test.mjs (PGlite, rollbacks included), and packages/shared/tests/business-ads.test.mjs and video-security.test.mjs.

Checks: supabase/tests/business-portal.test.mjs runs every rule above in PGlite (95 checks), and packages/shared/tests/business.test.mjs the labels, deal timing and targeting, standings and the team inbox's titles. supabase/tests/staging/business-portal.mjs runs the same rules on a real Supabase project through Supabase Auth (real sign-ups and email confirmation, with generated links so no email is sent), the REST API, Realtime (the presence channel, live message events across a suspension) and Storage, then deletes what it made; it refuses the production project:

SUPABASE_ACCESS_TOKEN=… STAGING_SUPABASE_REF=<staging ref> node supabase/tests/staging/business-portal.mjs

The staging project (campconnect-staging) is built like production: this repo's migrations through 36, the two in supabase/applied-outside-repo, then 37 onwards, and the seed.

Presence (migration 40). Testing presence on staging showed that Supabase Realtime checks a private channel's join with a broadcast read, so migration 22's presence policy, which allowed only presence reads, refused every join: "Active now" and the green dots stay empty. Migration 40 (20261102000000_presence_channel_join.sql) allows reading that one topic for either kind, still only for people who show their status (sending stays presence only, so there are no broadcasts to read); supabase/tests/presence-channel-join.test.mjs checks it.

Video tours (Mux)

Video is the main attraction, so it gets a real pipeline:

• Upload straight to the provider. POST /api/video/uploads creates a direct-upload URL at Mux and a media row; the browser (or the app, with Authorization: Bearer <token>) sends the untouched file there in resumable chunks with progress, so a dropped connection resumes instead of restarting. Nothing passes through our server.
• Processing. Mux converts the original into adaptive streams (HLS, up to 4K with video_quality: plus) and a poster frame. GET /api/video/{mediaId} checks the provider and updates the row until it is ready; the uploader polls it. Optionally set MUX_WEBHOOK_SECRET and SUPABASE_SERVICE_ROLE_KEY and point a Mux webhook at /api/video/webhooks/mux for push updates.
• Listings store a snapshot of ready videos in videos (jsonb); a trigger keeps has_video in sync. The feed query ranks has_video first, then newest, and the "Video tours only" filter uses the same column. Both rules live in the database, not in the web page.
• Recording in the browser. "Record a tour" opens the camera with a room-by-room checklist (front door, living room, kitchen, bedroom, bathroom, window view). Phones can also open the camera app directly. Any phone format is accepted, iPhone .mov included, up to 2 GB.
• Playback. Feed videos autoplay muted when in view, one at a time, with a shared mute button; detail pages show the video first in the gallery.

Environment: MUX_TOKEN_ID and MUX_TOKEN_SECRET (Mux → Settings → Access Tokens, Mux Video read + write) on the server only. The .env.example lists them. Mux bills per minute stored and delivered.

Architecture checklist

Decision	Status
Web: Next.js (React, TypeScript)	Done: apps/web
Mobile later: Expo (React Native)	Ready: the shared package was verified to type-check and bundle inside an Expo SDK 57 app (see Moving to iOS and Android)
Backend: Supabase (Postgres, auth, realtime, storage) with no custom server	Done: supabase/migrations, security enforced with row-level security
Monorepo from day one with Turborepo	Done: npm workspaces + Turborepo (turbo.json): apps/web, packages/shared, apps/mobile later
Everything that is not a UI component lives in packages/shared	Done: types, zod validation, all Supabase queries, price/date formatting, constants. The web app only keeps Next.js-specific code (server actions, cookies, cn() for Tailwind)

Why npm workspaces rather than pnpm: nothing to install for a new contributor, Vercel and Expo support it out of the box, and Turborepo provides the task pipeline and caching either way. Switching to pnpm later is a matter of adding pnpm-workspace.yaml and re-installing.

What is included

Area	Features
Accounts	Sign-up restricted to verified university emails (@txstate.edu), enforced in the form and by a database trigger; confirmation email; Google sign-in (optional, limited to the same domain); profile with photo, university (attached automatically from the email), program, bio; "Verified student" badge
Social	Following, like Instagram: a Follow button on every other person's profile ("Following" once you follow, "Follow back" when they follow you), follower / following counts (public, like the profiles) with your own two lists behind them and, on anyone else's profile, the mutual friends you share with them (row-level security keeps every follow readable only by the two people in it), a "Following" filter on Home → Posts (in the app, a row of the feed dropdown in the top bar), and a notification when someone follows you. Blocking someone removes the follow in both directions and stops new ones; row-level security only lets you add or remove your own follows
Profiles	TikTok style (see Profile in the feature map): @username, Following · Followers · Likes, Edit profile / Share profile with a QR code, classes per semester, the person's listings, and Posts, Classes, Reels, Saved and Liked tabs; each person chooses who can see their Classes (Friends by default), Saved (Only me) and Liked (Everyone); up to three pinned posts
Messages	Conversations with participants (a group is simply a conversation with 3+ people): 1:1 chats, group chats (create, rename, add people, leave), course chats (one per section of a class each semester, see Profile above: they fill themselves from the class lists, cannot be renamed or hand-filled, and are deleted when the semester ends after a week's notice), Supabase Realtime delivery, unread badges, "Mark all as read" (a pill above the app's inbox while Unread is chosen, a button in the website's chat list: one call, mark_conversations_read() in migration 27, marks every unread chat on screen read, the counts and the badge clearing at once; a chat with nothing new is left alone, as when it is opened), muting (a person's messages everywhere, one group, or every group chat, for 1, 8 or 24 hours or until unmuted: the message and the unread count still arrive, the notice does not; migration 26), rows that show full names only, photo messages, voice messages (recorded in the app with the microphone that takes Send's place while nothing is typed, up to five minutes, played back in a waveform bubble at 1×, 1.5× or 2×; on the website with the browser's player; migration 29), replies (in the app, swipe a message to the right to answer it, in direct and group chats alike; the reply quotes the original above its bubble and a tap on the quote jumps to it; the database builds the quote from the original itself, in migration 31, so nothing can be quoted that was never said; the website shows the quotes), red unread counts on the app's Messages tab and on its Chats and Groups labels, Snaps (a photo or video each person opens once, see ), posts, reels and listings shared from their Share button (as cards that open them), "Message" buttons that pre-fill a first message about the listing, and "Active now" or "Active 5 min ago" under the other person's name in a direct chat (anyone can hide theirs in Settings, see Activity status in the ). A table is ready for the mobile apps

Security is enforced in the database with row-level security: users can only edit their own listings, only conversation members can read or send messages, and images can only be uploaded to a user's own folder.

Project structure

apartment-book/
├─ apps/
│  ├─ web/                    # Next.js website (App Router, src/ layout)
│  │  ├─ src/app/             # routes: (app)/ has the main site, (auth)/ login + signup
│  │  ├─ src/components/      # UI: layout, home (Orbit, Buzz, Posts, Reels), housing (the Housing | Roommate | Marketplace bar and swipe), apartments, roommates, marketplace, messages, profile
│  │  ├─ src/lib/actions/     # server actions (create/edit/delete, auth, chat)
│  │  ├─ src/lib/supabase/    # Supabase clients for browser and server
│  │  ├─ src/proxy.ts         # auth guard: refreshes sessions, protects private routes
│  │  └─ e2e/                 # home-feed.mjs: Playwright check of the navigation, Home, Housing and the profile page on a desktop and a phone viewport
│  └─ mobile/                 # Expo app for iOS and Android (see apps/mobile/README.md)
│     ├─ src/app/(tabs)/      # bottom tabs: index.tsx (Home), discover.tsx (search, and what is popular on every campus), messages, housing.tsx (the Explore tab: Housing | Roommate | Marketplace), profile; create starts from the "+" on your photo in Home's top bar, and the bell (notifications.tsx) sits in its top-right corner
│     ├─ src/components/      # UI: home (the Home pager), housing (the Housing pager), profile (the TikTok-style profile), post cards, carousels, forms…
│     └─ e2e/                 # Maestro flows (flows/*.yaml), sim-seed.mjs test data, run.sh
├─ packages/
│  └─ shared/                 # platform-agnostic code reused by the website and the app
│     ├─ src/
│     │  ├─ types/            # Database types + models
│     │  ├─ schemas/          # zod validation for every form
│     │  ├─ queries/          # all reads/writes (apartments, items, roommates, messages, feed, follows, buzz, for-you, storage…)
│     │  ├─ for-you.ts        # blendForYou: the fixed pattern behind Home → Orbit
│     │  └─ constants.ts      # categories, amenities, currencies, HOME_SECTIONS, HOUSING_SECTIONS…
│     └─ tests/               # unit tests (npm run test:shared)
├─ supabase/
│  ├─ migrations/             # database schema, policies and functions, one file per change (first: 20260906000000_init.sql)
│  ├─ tests/                  # offline database tests in PGlite (npm run db:test)
│  └─ seed.sql                # starter list of universities
├─ scripts/                   # supabase-setup.mjs (one-shot setup), e2e-check.mjs and e2e-home-feed.mjs (live backend checks)
├─ turbo.json                 # Turborepo task pipeline (typecheck -> lint -> build, with caching)
└─ package.json               # npm workspaces root

Rules for packages/shared: no imports from next/*, react-dom or browser globals (window, document, localStorage); every query takes the Supabase client as its first argument; keep types/database.ts in sync with the migration. The web app's ESLint and type-check run through Turborepo (npm run check); the shared package's unit tests run with npm run test:shared (plain node --test on Node 22.18+, no network).

1. Run it locally

Requirements: Node.js 22.18 or newer (the shared unit tests load TypeScript files directly) and npm.

npm install

Project status

The Supabase project for this app (dskbzoqreandwwpxiplh, region us-west-2) is already set up: the migrations and the universities (with campus coordinates and the txstate.edu domain) are loaded, apps/web/.env.local is written, and the auth URLs point at http://localhost:3000. Sign-ups therefore require a @txstate.edu address right now. The steps below are for reference, for a second environment, or if you start a fresh project.

Each new migration has to reach the live project before the code that uses it: migrations 14, supabase/migrations/20260923000000_follows.sql (the follows table, the follow_stats and following_posts functions and the follow notification), 15, supabase/migrations/20260924000000_comment_threads.sql (post_comments.parent_id and score, the post_comment_votes table and the post_comment_vote() function), 16, supabase/migrations/20260925000000_comment_likes.sql (post_comments.likes and the post_comment_vote() function returning the score, the likes and your vote), 17, supabase/migrations/20260926000000_shared_posts.sql (messages.shared_post and the list_friends() function), 18, supabase/migrations/20260927000000_profile_page.sql (usernames, the who-can-see settings, the profile_classes table, likes readable only through functions, the profile_stats and post_view_counts functions and feed_posts.pinned_at), 21, supabase/migrations/20261010000000_private_follow_lists.sql (follows readable only by the two people in them, follow_stats giving everyone the same totals, the mutual_friends() function and are_friends() closed to the API), and 22, supabase/migrations/20261011000000_activity_status.sql (the private user_activity table, the touch_activity(), activity_status(), blocked_either_way_ids() and set_show_active_status() functions, the Realtime Authorization policies of the private presence:active channel, profiles.last_seen_at emptied and no longer written, mark_delivered_all() doing nothing while you hide your status, mark_conversation_read() doing nothing when there is nothing new, messages dated no later than when they are sent, chat members limited to their receipts and a group's name, notifications changed only once shown, and profiles and notifications granted to the API column by column), must be applied with SUPABASE_ACCESS_TOKEN=sbp_xxx npm run db:setup before this version of the website or the app is deployed, or every profile page, Home → Posts → Following, every comment thread, the share sheet and sending a share will fail (only messages that carry a share write shared_post, so plain chat keeps working). Without migration 18 a profile still shows its header, with zeros, and each tab says what it could not load, but searching people by name fails (the search also matches @usernames) and posts lose their "Liked by" line and newest comment. Without migration 21 other people's follower lists cannot load (on someone else's profile the counts open your mutual friends, which come from a function only migration 21 adds), and anyone with the public API key can still read who follows whom. Ship this version right after applying it, though: app builds and website versions from before it read other people's lists straight from the table, so once migration 21 is live they show empty lists (or only you) under the real counts until they get this code. Without migration 22 the private presence channel refuses every join and and do not exist, so no green dots show anywhere (avatars, the app's online friends row, Roommates' Online now) and chat headers show no activity status (the website's says "Direct message", as before); nothing wrong is shown and messaging keeps working. From migration 22 on, and are granted to the API column by column (so their system columns stay closed): a migration that adds a column to either must also , or the API cannot read it (and on that table fails until it does), and must never grant SELECT on the whole table again. Once it is live, older builds and website versions keep working but meet on the old public channel, so they and this version no longer see each other online, and they lose last-seen times ("Active 5m ago" read , now always empty); this version still shows their last-active times to the people they have written to, because their heartbeat () now stamps the private table. Their Settings can still hide the activity status but no longer turn it back on (only , which this version calls, can); the rest of such a save is kept. Right after , redeploy the website and publish the app's JavaScript to installed builds with (a build downloads it on its next launch and runs it from the launch after). Migration 24, , adds the section, the meeting times and the room on classes, the table and triggers behind the course chats, and the daily that warns members a week before a semester ends and deletes its course chats the day after; it schedules itself with pg_cron where that extension is enabled (Supabase dashboard: Database → Extensions), otherwise run once a day another way. Migration 25, , lets that function take the day it runs for and one term (), which is how exercises both the week-before notice and the deletion in PGlite, and moves the leave-the-chat step to an AFTER trigger so a changed section or a deleted chat never collides with the class row it is updating. When a semester ends, the class rows stay on the profile as that semester's history with no chat attached, and the new semester's list starts empty. Migration 28, , adds Snaps (the private bucket, the , and tables, , the "snap" notification, the , , , and functions, and every 10 minutes with pg_cron); it turns on pg_net, and (token mode) then keeps the project URL and service key in Vault so can delete files through the Storage API. Until it is applied the app's Snap screen opens but sending says Snaps aren't set up yet. Migration 29, , adds voice messages (the attachment kind, the bucket's audio types, "Sent a voice message") and the blurred preview and shape on a Snap's message ( takes an eighth, optional argument; and a Snap's going take the preview off); without it voice messages fail to send and Snaps go without a preview (the app falls back to the seven-argument call). Migration 30, , makes delete the file as soon as the last recipient closes it; without it the purge job deletes it within ten minutes instead. Migration 31, , adds replies (, the snapshot of the message answered, built by a trigger from the original); without it sending a reply fails (plain messages keep working). Migration 32, , has leave a Snap's blurred preview on its message, so opened Snaps keep showing it; without it an opened Snap shows its status on a plain dark surface. Migration 33, , adds the Snap activity log (, taking what the viewer's device can detect, , , , the "snap_activity" notification, and saying why a Snap goes); without it the app opens Snaps the old way ( with one argument, claiming nothing about detection), its delivered and capture reports go nowhere, Delete Snap says it is not set up yet, and nothing shows under the bubbles. Both migrations end with , so PostgREST answers the new signatures the moment they land. Migration 34, , corrects migration 33's trigger so a Snap that was viewed and closed logs nothing more (33 alone wrote "Snap deleted" after "Opened"); apply it with 33. Migrations 31 to 34 went live on 2026-10-23. Migration 37, (, Liked private by default, , the Notifications badge without messages), needs no app update first: before it the apps read Listings as private and fall back to . On its first run it also turns every Liked tab still on the old default (Everyone) private. Four migrations reached the live project from outside this repo on 2026-10-25, CampConnect Admin's (staff access and moderation at 15:11 UTC, its dashboard and a privilege hardening at 22:31 UTC); copies, a security review and the plan for bringing them into are in . Until that is done, never run : the CLI's own history on the live project is empty, so it would run every migration again. (needs ) runs a Snap's whole life between two throwaway accounts on the live project, through the same API the apps use, and removes them after. Migrations 41, , and 42, , bring Trust & Safety and Buzz v2 (see ). They are ; until they are, Buzz says it isn't available and posting is refused. They work with CampConnect Admin's migrations (staff list, two-factor rule, hide and restore, reports, suspensions; see ), checked on production's schema by .

Fastest path: the setup script

Create a personal access token at https://supabase.com/dashboard/account/tokens, then:

SUPABASE_ACCESS_TOKEN=sbp_xxx npm run db:setup      # migration + seed + .env.local + auth URLs
SUPABASE_ACCESS_TOKEN=sbp_xxx SUPABASE_PROJECT_REF=<ref> npm run db:check   # live end-to-end check

db:setup applies any migration that has not been applied yet and re-runs the seed as an upsert, so it is safe to re-run (for example with SITE_URL=https://yourdomain.com after you go live). db:check creates two temporary users, exercises listings, chat (including realtime), and photo uploads, then deletes them. Delete the access token from the dashboard when you are done with it.

Create the Supabase backend by hand (free)

1. Go to https://supabase.com, create an account and a new project. Pick a region close to your students. Save the database password somewhere safe.
2. In the dashboard open SQL Editor → New query and run each file in supabase/migrations/ in order (20260906000000_init.sql, then 20260907000000_geo_push_domains.sql). They create all tables, security policies, chat functions, PostGIS columns, the uploads image bucket, realtime for chat, push tokens and the university-email rule.
3. Run supabase/seed.sql the same way to load the universities with campus coordinates. Texas State University carries the txstate.edu email domain; to open the app to another university, set email_domain on its row (SQL: update universities set email_domain = 'utexas.edu' where name = 'University of Texas at Austin').
4. Authentication → URL Configuration:
   • Site URL: http://localhost:3000 for now (change to your domain later).
   • The migration enables the PostGIS extension automatically (it is available on every Supabase project).
   • Redirect URLs: add http://localhost:3000/auth/callback (and later https://yourdomain.com/auth/callback).
5. Authentication → Providers → Email is on by default. Keep "Confirm email" on for production. While developing you can turn it off so sign-ups log in immediately.
6. Optional, recommended: Authentication → Emails → Templates → Confirm signup: replace the link with {{ .SiteURL }}/auth/callback?token_hash={{ .TokenHash }}&type=signup&next=/settings/profile?welcome=1 so confirmation links work from any device or browser.
7. Optional: Google sign-in. In Google Cloud Console create OAuth credentials (Web application) with the redirect URI shown in Supabase → Authentication → Providers → Google, then paste the client ID and secret there and enable the provider.

Configure the website

cp apps/web/.env.example apps/web/.env.local

Fill in the values from Supabase → Project Settings → API:

NEXT_PUBLIC_SUPABASE_URL=https://xxxx.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...   (the anon / publishable key, never the service_role key)
NEXT_PUBLIC_SITE_URL=http://localhost:3000

Posting on Buzz also needs the server-only SUPABASE_SERVICE_ROLE_KEY, and MODERATION_AI_API_KEY is optional; see Buzz (anonymous).

Start

npm run dev

Open http://localhost:3000, create an account, set your university in Settings, and make a post (or list something on Explore). Open a second browser (or a private window) with another account to try messaging: messages arrive instantly without refreshing.

Other scripts (all run through Turborepo): npm run build, npm run lint, npm run typecheck, and npm run check which runs all three with caching.

2. Put it online (hosting + domain)

The website is designed for Vercel (the company behind Next.js; free Hobby plan is enough to start) with Supabase as the backend.

Current deployment

The site is live at https://apartment-book-vyass.vercel.app (Vercel project apartment-book in the vyass team of the yubrajbajagain2024-2020 account, Root Directory apps/web, production environment variables set, Deployment Protection turned off so the public can reach it). Supabase's auth Site URL points at that address. To ship a new version from this machine:

git push                 # keeps GitHub in sync (yubrajbajagain2024-byte/Apartment-Book)
vercel deploy --prod --yes --archive=tgz   # from the repository root

To deploy automatically on every push instead, connect the GitHub repository in the Vercel dashboard (Project → Settings → Git). The .vercelignore file keeps build caches out of CLI uploads. Run each new file in supabase/migrations/ on the live project (or npm run db:setup) before deploying code that depends on it.

Deploy to Vercel (from scratch)

1. Put the project on GitHub:

   git init
   git add .
   git commit -m "Apartment Book"
   # create an empty repo on github.com, then:
   git remote add origin https://github.com/<you>/apartment-book.git
   git push -u origin main
   

2. Go to https://vercel.com, sign in with GitHub, click Add New → Project and import the repo.
3. In the import screen set Root Directory to apps/web (Vercel detects the npm workspace automatically).
4. Add the three environment variables from .env.local, but with NEXT_PUBLIC_SITE_URL set to your real address (for now the https://<project>.vercel.app URL Vercel gives you).
5. Click Deploy. Every push to main redeploys automatically.
6. Back in Supabase → Authentication → URL Configuration, set the Site URL to your Vercel URL and add https://<project>.vercel.app/auth/callback to Redirect URLs.

Alternative without GitHub: npm i -g vercel, then run vercel inside apps/web and follow the prompts.

Connect your own domain

1. Buy a domain from any registrar (Namecheap, Cloudflare Registrar, Porkbun, GoDaddy, Google Domains alternatives). Something like yourbrand.com costs roughly USD 10–15 per year.
2. In Vercel open the project → Settings → Domains → add yourbrand.com and www.yourbrand.com.
3. Vercel shows the DNS records to create at your registrar (typically an A record pointing to Vercel's IP for the root domain and a CNAME for www). Add them in the registrar's DNS panel; the site is live on your domain once DNS propagates (minutes to a few hours). HTTPS certificates are automatic.
4. Update NEXT_PUBLIC_SITE_URL in Vercel to https://yourbrand.com and redeploy.
5. Update Supabase: Site URL https://yourbrand.com, add https://yourbrand.com/auth/callback to Redirect URLs.

The business portal on its own subdomain (business.yourbrand.com): add that domain to the same Vercel project (Settings → Domains, then the CNAME record Vercel shows), set NEXT_PUBLIC_BUSINESS_SITE_URL=https://business.yourbrand.com in Vercel and redeploy, and add https://business.yourbrand.com/auth/callback to Supabase's Redirect URLs (BUSINESS_SITE_URL=https://business.yourbrand.com npm run db:setup does that with the other auth settings). The proxy (apps/web/src/proxy.ts) serves the portal at that host's root and the student pages not at all; until then the portal works at /business on the main address.

Production checklist

• Supabase free projects pause after a week of inactivity; upgrade to the Pro plan (USD 25/month) before real users arrive, which also adds daily backups.
• Supabase's built-in email sender is rate-limited (a few emails per hour). For real sign-ups configure custom SMTP (Resend, Postmark, Brevo, SendGrid all have free tiers) under Authentication → Emails → SMTP Settings.
• Keep "Confirm email" enabled so only real mailboxes can sign up. Sign-ups are already limited to the university domains stored on the universities table.
• Map tiles come from OpenStreetMap, which is fine for a student site. If traffic grows, set NEXT_PUBLIC_MAP_TILE_URL to a MapTiler or Stadia tile URL with your key (both have free tiers).
• Turn on Vercel Analytics (free) in the Vercel dashboard for traffic numbers.
• Never expose the service_role key in the app or in a NEXT_PUBLIC_ variable. The website's pages use only the anon key, and row-level security does the rest. The service key's one server-side use is Buzz's moderated write API (SUPABASE_SERVICE_ROLE_KEY, read only on the server).

3. Moving to iOS and Android later

Nothing in the backend has to change, and the shared package already works in React Native: it was verified by creating an Expo SDK 57 app inside a copy of this monorepo, importing listApartments, apartmentSchema, formatPrice and timeAgo from @apartment-book/shared, type-checking it, and producing a Metro/Hermes bundle. The steps:

1. Scaffold the app inside the monorepo:

   npx create-expo-app@latest apps/mobile --template blank-typescript --no-install
   

2. Add these to apps/mobile/package.json under dependencies, then run npm install from the repository root:

   "@apartment-book/shared": "0.1.0",
   "@supabase/supabase-js": "^2.115.0"
   

   Expo configures Metro for monorepos automatically (SDK 52 and newer). Next.js and Expo both use React 19.2; if npm ever ends up with two React versions (symptom: "Invalid hook call"), pin the same react version in both apps.
3. Create the Supabase client the same way as apps/web/src/lib/supabase/client.ts, storing the session with expo-secure-store (see the Supabase Expo guide), and add the URL and anon key to app.json extra or an .env file.
4. Reuse the shared code in screens:

   import { listApartments, formatPrice, type ApartmentWithOwner } from "@apartment-book/shared";
   const page = await listApartments(supabase, { universityId, sort: "newest" });
   

   Chat uses the same supabase.channel(...).on("postgres_changes", …) subscription as apps/web/src/components/messages/chat-window.tsx. Three rules learned the hard way, all encoded in apps/web/src/lib/supabase/client.ts: set the user's token on the realtime socket before a channel joins (a channel that joins before the session is loaded stays anonymous and row-level security hides every event), give every subscription a fresh channel name, and pass postgres_changes_options: { wait: true } so SUBSCRIBED means the server is actually streaming. Photo uploads call uploadImage with an ArrayBuffer read from the picked image (await fetch(asset.uri).then((r) => r.arrayBuffer())).
5. Add "dev": "expo start" and "typecheck": "tsc --noEmit" scripts so Turborepo picks the app up, then ship with EAS Build. You will need an Apple Developer account (USD 99/year) and a Google Play developer account (USD 25 once). Push notifications for new messages can be added with Expo Notifications plus a small Supabase Edge Function triggered on message insert.

Until then, the site already works as an installable web app: on a phone, "Add to Home Screen" gives it an icon and a full-screen experience.

Regenerating database types

packages/shared/src/types/database.ts is written by hand to match the migration. If you change the schema, either edit it or generate it with the Supabase CLI:

npx supabase login
npx supabase gen types typescript --project-id <your-project-ref> > packages/shared/src/types/database.ts

Ideas for later

The social network first: pages for clubs and organizations, campus events, campus news, calls switched on, and more campuses. For the Explore tools: saved searches with alerts and ratings for sellers.