A university social platform · Product & engineering

Built to connect
a real community.

I designed, built, and launched Inlooveu: a place for university students to discover people, express their interests, and turn a first connection into a conversation.

1,800 registered accounts

Historical MongoDB count recorded by the founder. This is a registration count, not an active-user metric.

About this number ↓
React / TypeScript / Express / MongoDB / Socket.IOFrom an idea to a working, deployed product.

02 / The experience

From a profile
to a conversation.

A journey from the registration forms to profiles, discovery, and messaging. The form walkthrough stops before final submission.

  1. Walk through the registration forms.

    Email and password begin the flow. Name, date of birth, faculty, degree, semester, and preferences lead to a biography and interests. This walkthrough stops before final submission.

    Registration forms · Academic details · Preferences and interests
  2. Make a profile feel like a person.

    Email-confirmed registration, multiple photos, a biography, and a catalog of interests give people a way to introduce themselves. Photo cropping happens in the browser.

    Account lifecycle · Profiles · Canvas image preparation
  3. Give a first connection somewhere to go.

    Discovery uses gender preference and confirmed profiles. Cards support mouse and touch interactions; likes and reciprocity lead people toward a conversation.

    Preference-based discovery · Likes · Reciprocity detection
  4. Look beyond the first photo.

    Open the lower detail control to read the biography, degree, semester, and interests without leaving the card. Photos change within the same card.

    Photo gallery · Expandable biography · Interests
  5. Keep the conversation when people return.

    Messages are saved in MongoDB before the client emits the saved record through Socket.IO. Returning to a conversation loads its history through the API.

    Persistent messages · Real-time events · Restored history

03 / Engineering notes

Save. Emit. Recover.

The central decision: a live event distributes a message; the database preserves the conversation. Those responsibilities stay distinct.

01 /

Persistence before notification

The client waits for the message POST to succeed before emitting its result. A separate history request restores the stored conversation. Delivery acknowledgments and retry deduplication would be separate reliability improvements.

02 /

A connected account lifecycle

Email verification, JWT sessions, bcrypt password hashing, and account recovery connect the onboarding experience to the private application. An institutional-domain badge is separate from email confirmation.

03 /

Image preparation at the edge

Canvas prepares cropped profile photos in the browser; external storage handles the resulting files. A windowed interest selector supports a large catalog without rendering every option at once.

04 / Ownership over time

Build the product.
Keep it working.

My role covered product decisions, interface design, frontend, backend, and deployment. The original launch and the 2026 recovery are two distinct stages of that work.

Original product

Launched for a university community.

React and TypeScript on the frontend; Express, Socket.IO, and MongoDB behind the account and conversation flows. The static frontend and API used Render, with a custom domain, S3 photos, and SMTP email.

Product design · Full-stack development · Cloud deployment

Recovery / 2026

Bring the existing application back.

The recovery preserves the existing MongoDB accounts and messages. Docker, Caddy, and HTTPS run on an existing Hetzner server. New photos use the existing Cloudinary account; email uses SMTP with mandatory STARTTLS.

Session and chat-membership controls · Private-field protection · Maintenance

The local walkthrough uses accessible original Cloudinary photos. Historical S3 photos remain unavailable and their references are preserved; new uploads use Cloudinary.

A note on the adoption evidence

The founder recorded 1,800 registered accounts in a historical MongoDB count on another computer. That count is owner-reported and was not independently reproduced during the 2026 recovery.

A separate preserved export contains 681 account records and 2,129 distinct, nonempty stored messages. It describes a different cut of the application’s history; those messages must not be presented as the same cohort or period as the 1,800-account count.

The preserved export includes missing account and chat references. Registration records are not unique-person verification, and no MAU, DAU, or retention claim is made. Overlapping backups are not added together.

Pierre Burciaga / Software engineer

Let's build the next
useful thing.