Kamerly is a room-rental platform: tenants search, view and book accommodation across the Netherlands, and landlords manage listings, availability and payouts. Two sides, two very different sets of expectations, one codebase. It shipped in eight months with six developers.
Pick the boring parts early
Vue on the front, Node and PostgreSQL behind it, Stripe for payments, Socket.io for the messaging between tenant and landlord. None of that is a novel choice, and that is the point. On a two-sided marketplace the interesting problems are search relevance, availability and trust — not which framework renders the listing card.
Model availability before you model anything else
Every hard bug on a booking product traces back to the availability model. Rooms have viewing windows, minimum stays, overlapping enquiries and holds that expire. We built that model first, wrote tests against it before there was a UI, and everything downstream — search filters, the booking flow, the landlord calendar — became a read of one well-understood structure.
Search is a product decision, not an infrastructure one
The first version ranked purely on distance and price and it felt wrong to everybody who used it. What tenants actually wanted was a blend: commute time, whether the landlord replies, how recently the listing was updated. That is a conversation with the client, run against real listings, not something you tune in isolation.
What we would do differently
We integrated maps before we had settled the availability model, which meant re-doing part of the map layer when holds arrived. Order matters: build the thing that everything else reads from, then build the things that read from it.
