Plekkie

Carpooling for a group event gets arranged in a group chat. Someone asks who can drive, a few people reply, and twenty messages later nobody knows which car is full. Plekkie replaces that thread with one page that shows every car and every seat.

One person creates a ride and shares the link. Drivers add their car with the number of seats, a departure time and a place. Everyone else taps an empty seat on a top-down car plan. People without a seat show up in a list, so drivers can see who still needs a ride. Recent rides are remembered on the device.

Without accounts there is no user to check permissions against. The room code is the key instead. The app sends it in an x-room-codes header on every request, and row level security in Postgres only returns rides whose code was sent, at most ten per request. Creating a ride is open to anyone. Changing or deleting a ride through the public API is not.

Two people tapping the same seat is handled by a unique constraint on car and seat. The second insert fails and that person gets a short message. Live updates come from a database trigger that sends an empty signal to the room channel, after which each open page fetches the room again through the same policies. No ride data goes out over the broadcast.

A daily cron job removes rides seven days after their date, or after 30 days without activity.

Kevin Steba and I came up with Plekkie and built it together. It launched on 12 September 2026. That covers the idea, the Dutch landing page and the room interface with its car plans, the Supabase schema with its policies, triggers and cleanup job, and the deployment on its own domain.

Skipping accounts makes joining a ride one tap. It also means the usual protection is gone, so it has to live somewhere else. Here it lives in the database, where it applies to every request the app makes.