P.02Internal prototype

RaceShare

Matchmaking platform between drivers, sponsors and motorsport professionals: listings, profiles, real-time messaging.

Period
August 2025 – June 2026
Role
Full architecture, backend, database, interface.
Stack
  • React 19
  • Express 5
  • PostgreSQL
  • socket.io
  • JWT
  • bcrypt
  • helmet
  • sharp
  • multer

Reference points

  • 6

    backend services

    auth, listings, contacts, messages, photos, posts

  • 3

    separated roles

    administrator, driver, sponsor

  • 10

    months of development

    first to last commit, August 2025 – June 2026

The problem

A driver looking for a budget and a sponsor looking for exposure currently only meet through personal connections. The problem is not displaying listings: it is making first contact possible without exposing everyone's details to everyone.

What was built

  • 01

    Three distinct roles — administrator, driver, sponsor — with separate views and permissions.

  • 02

    Real-time messaging on socket.io, with a contact-request mechanism: you cannot write to someone until they have accepted.

  • 03

    A tagged listings system, allowing filtering by discipline, category and need.

  • 04

    A photo manager that resizes on upload rather than on display.

  • 05

    Public profiles, a contact directory and a posts feed.

Architecture

if acceptedDriveraccountSponsoraccountRequestqueueJWT + bcryptrolesPostgreSQLlistings / tagssocket.ioopen conversation
Exchange partitioning: nothing passes between two accounts without acceptance.

Technical decisions

Contact request before messaging

A platform where a sponsor receives thirty unsolicited messages a day dies in three weeks. Conversations only open after explicit acceptance, and pending requests live in a separate queue. That is a product constraint before being a technical one, and it drove the data model.

Resizing on upload

Photos go through sharp at upload time and are stored at the size they are served. The server never redoes the work on each display, and an 8 MB phone photo never becomes 8 MB of bandwidth for every visitor.

Rate limiting and security headers from the start

express-rate-limit on the authentication routes and helmet across the whole application. On a site where accounts can be created, a login route without limiting is an invitation to credential stuffing. It is one line of code on day one and a full rework on day six hundred.

What it demonstrates

Multi-role authentication, real time, exchange moderation, server-side image processing.