The brief.

Vroom started as a business proposal for a peer-to-peer rental marketplace where car owners list idle vehicles for renters to book, Turo-style, aimed at travelers and remote workers. From that vision I scoped and built the core rental engine: the parts that had to be solid before any marketplace layer made sense. That meant accounts, vehicle inventory, and bookings.

Architecture.

Server-rendered with Express and EJS, so pages are assembled on the server rather than shipped as a client bundle. The interface is styled in Tailwind CSS, compiled through its own build step. Authentication runs on express-session with bcrypt-hashed passwords. The data layer is MariaDB hosted on Railway, accessed through the native driver. I wrote the schema and every query by hand instead of reaching for an ORM, because I wanted to understand exactly what each query did rather than trust an abstraction to do it for me. Configuration lives in environment variables, requests are logged with Morgan, and the app is deployed on Vercel against the Railway-hosted database.

The interesting problems.

• Authentication, done properly. Session-based login with bcrypt password hashing means no plaintext and no shortcuts. Getting the session lifecycle and password handling right is unglamorous, but it has to be correct.
• Modeling the data by hand. Users, vehicles, and bookings are related tables joined with SQL I wrote myself. It's a from-scratch relational model rather than an ORM-generated one, with my own scripts to initialize, seed, and test the database.
• Wiring up hosted infrastructure. Moving the database to a managed Railway instance meant handling connection config, environment separation, and a deploy that talks to a remote DB. It's the unglamorous plumbing that makes a project run for other people, not just on my machine.
• Server-rendered, on purpose. Choosing EJS and server rendering over a client framework kept the app simple and fast for its scope. The right tool for the job, not the flashiest one.
• Booking and availability. The platform models bookings around users, vehicles, and rental dates. The next hardening step is date-range conflict handling so the same car can't be double-booked.

What I'd build next.

The proposal imagined a revenue-generating marketplace. The shipped app is the core engine. The honest roadmap is a payment flow to realize the marketplace vision, peer-to-peer listing features that let owners put their own cars up, and date-overlap conflict handling so bookings can't collide.