Marketplace

Ridezio

Rent a bike or a car from a local shop, without ringing round

Shops list their vehicles, people book them for a set of dates, and both sides work from the same booking. I built it to launch as a real product after a trip where finding a bike meant calling shop after shop. It works end to end. It never found its users, so it sits here as the one that did not take off.

View source★ 1

Role: Solo — full stack, API design, data modelling
Timeline: 2025
Status: Live
Stack: Next.js, TypeScript, Tailwind CSS, shadcn/ui, PostgreSQL, tRPC

github.com/ujen5173/Ridezio

01 — Context

The problem

Renting looks like a search problem and behaves like a calendar problem. Someone filters by type, price and place, but each result only means anything for a particular set of dates — and those dates are shared with everyone else looking at the same vehicle.

Shops need close to the opposite: one honest view of their vehicles, what is booked, and the gaps in between. The same records have to serve both sides without either one being shown something untrue.

Where this one came from

Two founders, an air mattress, and a lot of unglamorous work.

The idea started on a trip with friends. Finding a bike to rent meant calling shops one after another, and half of them never picked up. That afternoon stayed in my head for months.

Around the same time I was reading about Airbnb's early years — renting out air mattresses in their own apartment, selling cereal to keep the lights on, taking the listing photos themselves because nobody else was going to. None of that looks like a tech company. It looks like people doing slow, manual work until a part of it is worth writing code for.

So I built Ridezio the same way round: ask the shops how they track bookings first, put their notebook into a database, and only automate the parts that actually hurt. It never got the Airbnb ending. Going and looking before building is the habit I kept.

02 — Decisions

How I approached it

A booking is a date range

Bookings are stored as ranges instead of two separate columns compared in my own code. Whether a vehicle is free on given dates becomes a question the database answers directly, rather than a loop over existing bookings.

Filters that stack into one query

Type, price, place and dates all become conditions in a single query. Adding a new filter means adding a condition, not another pass over results that have already been fetched.

A map beside the list

Listings carry coordinates, so 'near me' is an area on a map rather than a match on the spelling of a town — which matters where the same place is written three different ways.

One booking flow, two sides

Requested, confirmed, active, returned, cancelled. Shops and renters look at the same booking from different sides, instead of two separate flows that slowly drift apart.

03 — Structure

How it fits together

Discovery: Filters · Map area as a filter · Availability check
One piece of state feeds both the map and the list.
Booking: Booking states · Range overlap · Exclusion constraint
The database refuses a double booking, so the code does not have to be perfect.
API: tRPC · Separate public and shop views
Shop numbers never travel out on the public endpoint.
Data: PostgreSQL · daterange + GiST · Fleet tables
Date ranges are built in, so checking overlap is an index lookup.

04 — Problem solving

What was actually hard

Problem

Two people booking the same vehicle for overlapping dates in the same second would both pass a check written as 'fetch the bookings, then decide'. The checking and the saving were not one step, so both could win.

✓

Solution

I moved the guarantee into the database with an exclusion constraint: it will not store two overlapping bookings for the same vehicle. The app still checks first so the message is friendly, but being right no longer depends on that check winning the race.

sql

1-- The database decides what overlaps, not the request handler.2ALTER TABLE reservations3  ADD CONSTRAINT no_overlapping_bookings4  EXCLUDE USING gist (5    vehicle_id WITH =,6    daterange(start_date, end_date, '[)') WITH &&7  )8  WHERE (status IN ('confirmed', 'active'));

Problem

The map and the list disagreed. Moving the map fetched listings, changing a filter fetched them again, and the two answers arrived at different times — so the page flickered between them.

✓

Solution

I folded both into one piece of state by treating the visible map area as just another filter. One fetch feeds the map and the list, so panning and filtering are the same operation underneath and there is nothing left to fall out of step.

05 — Result

Where it landed

Double bookings: Blocked by the database
Search: Knows the dates
Discovery: Map and list, one query
Sides: Shop and renter

What I'd do differently

I did not think cancellations through. Freeing up the dates is easy; deciding what happens to a rental that is half over, and who carries the cost, is a product question I answered in code before I answered it on paper. Next time I draw the whole booking flow, with the money written on each step, before the first migration.