RentNear

Inspiration

Most of us own gear we use a handful of times a year — a pressure washer, a DSLR, a tent, a drill — that sits idle the rest of the time. Meanwhile the person two streets over is about to buy the same thing for a single weekend project. Renting from a faceless depot across town is expensive and inconvenient; borrowing from a neighbor is cheap and local but has no trust layer, no scheduling, and no way to find who has what. We wanted to build the "Airbnb for stuff" — a marketplace that makes idle items earn their keep and lets renters get what they need from someone close by, with enough structure (identity, reviews, bookings, messaging) that strangers can transact with confidence.

What it does

RentNear connects people who have items sitting idle with people who need them for a day or a weekend.

List in minutes — owners post an item, set a daily rate, pick a category, and upload photos. Addresses are geocoded to coordinates so listings can be found by location. Browse by location and category — renters search nearby listings filtered by category and distance. Request and manage bookings — renters request a date range; the booking moves through pending → confirmed → active → completed, and the owner is notified at each step. Message before committing — a built-in inbox lets renters and owners chat about a specific listing before money changes hands. Two-sided reputation — after a completed booking both parties review each other. Scores are split by role, so a user carries a separate owner rating and renter rating rather than one blended number. Stay in the loop — in-app notifications fire on booking requests, status changes, new messages, and new reviews.

How we built it

RentNear is a single Next.js 16 app using the App Router, React 19 Server Components, and Server Actions for every mutation — there's no separate REST API layer.

• Framework — Next.js 16 (App Router, Turbopack), TypeScript, React 19 Server Components & Server Actions.
• Auth — Clerk handles sign-up/sign-in and sessions. A Svix-verified webhook (/api/webhooks/clerk) mirrors user.created / user.updated events into our own users table, keyed by clerk_id, so the rest of the app joins against local rows instead of calling Clerk on every request.
• Database — Aurora DSQL (a distributed, Postgres-compatible engine) accessed through Drizzle ORM. Connections mint a short-lived IAM auth token per connection, with a fallback to a local DATABASE_URL for development.
• Images — listing photos upload straight from the browser to AWS S3 via presigned PUT URLs, so the file bytes never pass through our server; only the resulting public object URL is stored.
• Geocoding — addresses are turned into latitude/longitude with OpenStreetMap's Nominatim, kept behind a small geocode.ts seam so the provider is swappable.
• Messaging — conversations are scoped to a (listing, renter, owner) triple and delivered with lightweight polling — no websocket infrastructure to operate.
• Notifications — title, body, and link are snapshotted at write time, so rendering the notification feed needs no joins.
• Styling — Tailwind CSS v4 with shadcn/ui components.

Challenges we ran into

Aurora DSQL's DDL limits — DSQL doesn't support the incremental drizzle-kit push workflow we're used to; certain schema changes fail. We worked around it by writing raw-SQL migration scripts (in scripts/) that we run manually per change, plus targeted backfill scripts (e.g. geocoding existing rows). Short-lived database credentials — because DSQL authenticates with IAM tokens that expire (~15 minutes), the connection layer had to mint a fresh token per connection rather than hold a long-lived secret, which changes how the DB client is constructed. Keeping Clerk and our DB in sync — identity lives in Clerk but our relational data needs local user rows. Getting the webhook right (verifying Svix signatures, handling create vs. update, and not trusting unsigned calls) was essential before anything else could reference a user. Real-time-ish messaging without the infrastructure — rather than stand up websockets for a hackathon, we modeled conversations carefully and used polling, trading instant delivery for something far simpler to ship and operate.

Accomplishments that we're proud of

A complete rental loop you can actually walk through: sign up → list an item with photos → discover it by location → message the owner → book it → complete it → review each other. Role-aware reputation — separating owner and renter ratings (driven by a direction field on reviews) is a small modeling decision that makes the trust signal genuinely meaningful. A clean, modern stack with zero hand-rolled API routes — every mutation is a typed Server Action, and the only API endpoint is the Clerk webhook. Browser-to-S3 uploads that keep image bytes off our server entirely. Running on a distributed Postgres (Aurora DSQL) and solving the real operational quirks that come with it.

What we learned

leeding-edge versions move fast — Next.js 16 and React 19's Server Actions reshape how you think about data flow, and we leaned on the in-repo docs rather than assuming older conventions. Managed identity (Clerk) is a huge accelerator, but you still need a deliberate sync strategy to bring that identity into your own data model. Newer database engines like DSQL trade some developer-experience conveniences (incremental migrations, long-lived credentials) for scale and resilience — and you have to design your tooling around those trade-offs from day one. Picking the simplest thing that works (polling over websockets, snapshotted notifications over join-heavy reads) let us ship more of the product surface in the time we had.

What's next for RentNear

Payments — wire up Stripe end to end (checkout, deposits/holds, and commission-based payouts to owners). The payments table and dependency are already scaffolded. Availability calendars — prevent double-booking and let owners block out dates. Smarter discovery — map view, radius search refinements, and better category/keyword filtering. Real-time messaging and notifications — move from polling to push/websockets. Trust & safety — ID verification, damage deposits, and dispute resolution. Mobile — a responsive PWA or native app for listing and booking on the go.

Built With

• aurora
• dsql
• next.js
• vercel