Ayush

I'm a full-stack developer who builds things for the people around him. CampusZen is my primary project: a social network scoped to college students, with the whole product — sign-up, verification, feeds, profiles, colleges, moderation — designed around how campus life actually works.

I work in the open. The codebase, the product requirements, the design system and the developer guide are all public, and the project ships under the AGPL-3.0 licence. Anyone can read how it works, run it locally, or contribute to it.

Campus life was scattered. The people in your batch, the department, the club, the seniors worth following — each group lived in a different app, and the useful signal got buried under everything else. A student network that only worked if you already had an audience wasn't solving that.

So I built the small version first and made it work properly. The MVP is deliberately narrow: 500-character posts with photos, video and polls, chronological feeds, replies, reposts, hashtags, college pages, bookmarks, and notifications. No DMs, no stories, no recommendation black box. Everything in the core loop works reliably before anything decorative is added.

The other constraint was the device. Most students I'm building for are on mid-range hardware and ordinary mobile networks, so the app stays fast and light, and the design stays quiet — one accent colour, hairline borders, no card shadows. Content first, chrome out of the way.

• Students first — a scoped product, not a general network. Campus is the context the whole thing is designed around.
• Small on purpose — a narrow MVP that works beats a wide one that doesn't. Communities and realtime chat come later, on a foundation that already holds.
• Privacy by default — private accounts, follow requests, block and report on every piece of content, and no selling of data. Ever.
• Open and auditable — public repository, published requirements and design docs, and an AGPL licence that keeps derivatives honest.

The full product plan — MVP, V1, V2 and V3 — is written up in the public docs.

The fastest way to reach me is a DM on X, or an issue on the repository if it's a bug or a feature request. Both are read by me, and issues keep the discussion public and searchable for the next person with the same problem.

• Say hello, report a bug, or request a feature — open an issue on GitHub.
• Short questions and quick replies — @User_Synax on X.
• Something urgent or private — the privacy policy lists the right address for data and privacy requests.