Everything I learned building rental marketplaces (and why I stopped doing it from scratch)

Marko Ristic — Thu, 05 Mar 2026 21:42:19 +0000

I've built three rental marketplaces in the past two years. Every single time, I told myself "this time it'll be faster." Every single time, I was wrong.

The first one took me about four months. The second one, three months. By the third one I realized something — I was spending 80% of my time on stuff that had nothing to do with what made each marketplace unique.

The same 15 problems, every time

Here's what ate most of my time, in order of how much I underestimated each one:

Messaging. You think it's just a chat box. Then you need real-time delivery, read receipts, unread counts in the nav, conversation lists, notification emails when someone doesn't reply, and suddenly you've spent three weeks on "just a chat box."

Reservations. Date picking UI, availability calendars, booking status workflows (pending → confirmed → active → completed → cancelled), conflict detection, timezone handling. Every edge case you didn't think of shows up in production.

Auth. Not just login/signup. Email verification flows, password reset, Google OAuth, role-based access (regular user vs admin vs superadmin), session management, protected routes, middleware.

Image handling. Upload, resize to three sizes (thumbnail, medium, large), store somewhere reliable, serve fast, handle failures, reorder in the UI. I tried local disk, then S3, finally settled on Cloudflare R2.

Reviews. Sounds simple until you need mutual reviews (both parties review each other), rating aggregation, review moderation in admin, preventing reviews before a completed reservation.

Search and filters. Price range, category, location, text search, sorting, pagination. Then mobile filters UI. Then URL state sync so filtered results are shareable.

Admin panel. User management, listing moderation, reservation oversight, analytics, newsletter. Every marketplace needs one, nobody wants to build one.

I'm not even counting email templates (built 12), SEO, structured data, OG images, notification system, favorites/saved listings...

The turning point

Halfway through marketplace number three, I had a moment of clarity. I opened my second marketplace repo and my third one side by side. I was literally copying functions between them and adjusting variable names.

So I stopped. Took a step back. And spent the next few weeks doing something I should have done after the first build — I extracted everything into a single, clean, config-driven boilerplate.

What "config-driven" actually means

I didn't want another codebase where you have to grep for "Airbnb" and replace it with your brand name. Every marketplace-specific decision lives in a config/ directory:

// config/pricing.ts
export const pricingConfig = {
  currency: "USD",
  periods: {
    hourly: true,
    daily: true,
    weekly: true,
    monthly: false,
  },
}

Categories, pricing model, theme colors, homepage layout, feature toggles, email branding — all config files. Change them and the entire UI adapts. No hunting through components.

The feature flags were the part I'm most happy with. Nine boolean flags that cleanly remove entire features:

// config/features.ts
export const features = {
  messaging: true,
  reservations: true,
  reviews: true,
  favorites: true,
  maps: false,
  aiAssistant: false,
  notifications: true,
  newsletter: false,
  premiumListings: false,
}

When you set messaging: false, every chat button, conversation page, nav link, unread badge, and socket connection disappears. Context providers return safe defaults. No dead code, no crashes.

The stack

After trying different combinations across three builds:

Next.js 15 App Router — server components for the heavy pages, client components where I need interactivity. API routes keep everything in one repo.
Tailwind v4 — config-driven theming works perfectly with this. Change the primary color in one config file, done.
Prisma + PostgreSQL — type-safe queries, clean migrations, schema file doubles as documentation.
NextAuth.js — Google + email auth with role-based access.
Socket.io — real-time messaging. Optional, controlled by feature flag.
Cloudflare R2 — image storage. Cheap, fast, S3-compatible.

Nothing exotic. I wanted a stack that any Next.js developer could jump into and understand immediately.

What I'd do differently

If I started over today:

Start with the config layer. I built features first, then made them configurable. Should have been the other way around.
Feature flags from day one. Adding them retroactively to messaging was painful. Building with flags in mind from the start is so much cleaner.
Don't build your own email templates from scratch. I spent way too long on pixel-perfect emails. Should have started with a solid base and customized.

Now I'm selling it

I packaged the whole thing up and put it on Gumroad. One-time purchase starting at $249 — you get the full source code, run a setup wizard, and you've got a working rental marketplace.

Not for everyone. But if you're about to build something like Airbnb for cameras, tools, parking spots, studios, whatever — it'll save you months.

Live demo with 50+ listings: marketplace-kit-demo.vercel.app

Full breakdown: kit.creativewin.net

Happy to answer questions about any of the technical decisions.