Building the operating system behind a vehicle rental marketplace.

Vehicle rentals create more state than a typical marketplace listing flow. A booking is not finished when checkout succeeds. It has to move through owner acceptance, payment authorization or future payment setup, pickup, active rental period, return, review, payout, and possible support cases.

That complexity made the product a domain-modeling challenge. The goal was to make renter and host experiences feel understandable while keeping the underlying booking, money, handoff, and support states explicit enough for operators to reason about.

The app separates authentication from operating context. A person can rent personally, host personally, act inside a company, invite teammates, or use admin surfaces depending on memberships and roles.

This model affects nearly every feature. Listings, bookings, chat, notifications, dashboards, Stripe readiness, and admin actions all depend on whether the user is acting personally, through a company, or as a platform operator.

Hosts need to satisfy readiness checks before their vehicles become useful supply. Listings can belong to individuals or companies, move through draft and published states, include media and structured vehicle data, and expose public search information without leaking operational details too early.

Availability is also not a static calendar. Listing rules, price rules, time slots, occupancy, booking holds, and listing-local timezone behavior all shape whether a renter can reserve a vehicle.

The booking system distinguishes customer-visible status from operational overlays. A booking can be pending, confirmed, active, completed, cancelled, or declined, while also carrying payment state, handoff proof, no-show claims, support cases, and audit logs.

I centralized human-triggered status transitions so booking changes, notifications, chat lifecycle messages, optimistic concurrency, and booking references could stay aligned. Scheduled jobs handle expiry, auto-confirm/decline, active/completed transitions, future payment work, and reminders.

The product treats pickup and return as operational phases, not as passive booking timestamps. Smart Handoff flows capture confirmations, photos, proof items, evidence grades, and magic-link access for participants.

No-show handling is where the marketplace becomes an operations product. Claims can freeze bookings, create support cases, allow thaw or resume flows, and escalate after grace periods. End-phase scenarios are more severe because the vehicle may not have been returned.

The money layer is designed around the fact that marketplace bookings settle over time. Near-term bookings authorize the card first and capture later. Far-future bookings save a payment method and charge closer to the trip.

The system tracks payment state, future-payment processing, refund decisions, receipts, Stripe webhook events, payout eligibility, payout records, and reconciliation. Admin and staff surfaces expose finance diagnostics so operational state is visible instead of hidden inside Stripe.

A marketplace needs tools for the people operating it after launch. Hobblix includes admin surfaces for bookings, users, companies, support cases, complaints, cron controls, emails, payments, payouts, reports, diagnostics, and documentation.

The documentation is part of the engineering work. The repo contains system maps, flow maps, domain docs, production-readiness notes, and operations references so the system can be understood beyond the code itself.