Self-drive car rentals without the friction — building Carvar

Renting a car in Bangalore cost more in friction than in money

Self-drive rentals existed in Bangalore in 2022. The problem was using them. Prices were high enough to make casual renters think twice, and the booking experience made them think a third time: clunky flows, phone calls to confirm, paperwork at pickup, ambiguity at return. Renting a car felt like a procedure. Booking a cab, a flight, a hotel — those had become a few taps. The gap was the opportunity.

The stakes for a challenger were the obvious ones. This is a market where you win customers on price and keep them on experience, and where one botched booking — a car that isn't there when promised — costs you the customer and their entire circle. Cheap and unreliable is not a position. Cheap had to come from somewhere structural.

Why automation had to be the business model, not a feature

Here is the economics that drove every technical decision. A rental marketplace runs on thin margins. Every manual touchpoint in the rental loop — a staff member confirming a booking by phone, paperwork at handoff, someone chasing a late return — is labor, and labor per rental sets a floor under your prices. The incumbents weren't expensive out of greed. They were expensive because their operations were manual, and the price reflected the payroll.

So undercutting them with marketing spend or subsidy wasn't interesting — that kind of "cheaper" evaporates. The bet behind Carvar was different: automate the entire loop, from booking through return, so that serving one more rental costs close to no additional labor. Then the lower price isn't a promotion. It's structural. A competitor can match it only by rebuilding their operations.

That bet has a hard constraint attached. When inventory is physical, correctness isn't negotiable. An overbooked SaaS seat is an apologetic email; an overbooked car is a person standing in a parking lot at 6am with plans and no vehicle. Whatever the system looked like, double-booking had to be impossible — not unlikely, impossible.

From search to key return without a phone call

What I built was the full loop, automated: browse the fleet, pick a car and dates, book, pay, pick up, return. No call-to-confirm step, no human in the critical path. The technical choices each trace back to the economics above.

• Next.js on React for the frontend, because a consumer marketplace lives on discovery and first impressions. Server-rendered pages meant fast loads and search-engine visibility — for a price-led challenger, organic search is the marketing budget you don't have to spend.
• PostgreSQL for the data, because bookings are relational and transactional by nature. Cars, customers, reservations, payments — and above all, the guarantee that two confirmed bookings can never overlap on the same vehicle. That guarantee belongs in the database, enforced by constraints and transactions, not in application code hoping it checked fast enough.
• Express for the API: a thin, deliberately boring layer between the two. The product was the rental experience, not the architecture, and a stack with no surprises keeps the attention where the differentiation actually is.

The discipline throughout was subtractive. Every step in the booking-to-return flow had to justify its existence, because every step is somewhere a customer hesitates — and somewhere a manual process tries to grow back.

The product was the absence of steps

What came out the other end was a rental experience that finally matched how people book everything else: simple, self-service, end to end. Car rentals became accessible to a wider audience — people for whom the old friction, as much as the old prices, had been the barrier. And the experience held from the first tap to handing back the keys, because the loop was designed as one piece rather than a booking form bolted onto a manual operation.

The win wasn't a clever stack. It was the removal of every step that didn't need to exist — and the unit economics that removal made possible.

If you're building a marketplace on thin margins

Cars are incidental. The shape — physical inventory, price-sensitive customers, margins that punish manual work — is everywhere. What transfers:

• Cost to serve is the strategy. If your price advantage depends on manual operations staying cheap, you don't have a price advantage. Automate the loop or the promise breaks at scale.
• Automate end to end, not the easy 80%. A booking flow that ends in "we'll call you to confirm" has automated nothing — the labor floor is still there, and so is the friction.
• Put inventory integrity in the database. When the inventory is physical, enforce correctness at the data layer, where it can't be raced around. Everything above that layer can be iterated. That guarantee can't be optional.
• Choose boring technology when the product is the differentiator. Proven relational databases and unremarkable frameworks buy speed and predictability — the two things a small team actually competes with.

If you're weighing a build like this — a marketplace where the margin lives or dies on operations — these are the decisions that decide it, and most of them get made before the first line of code. That early conversation is the one worth having, and I'm easy to reach.