Case study

Self-drive car rentals without the friction — building Carvar

Bangalore · 2022 · Self-drive rental marketplace

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.

Manual touchpoints — confirm by phone, paperwork at handoff, chasing late returns — feed into labor per rental, which sets a floor under price. When Carvar collapses those touchpoints, the labor floor drops and the low price becomes structural. INCUMBENT confirm by phone paperwork at handoff chasing late returns labor per rental staff on every loop price floor payroll CARVAR touchpoints collapsed ≈ no labor per extra rental price floor drops structural
Manual touchpoints become labor per rental, which sets a floor under price; collapse the touchpoints and the floor drops — making the low price structural, not a promotion

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.

Two lanes compared: the old way takes five manual steps — search, call, negotiate, paperwork, key handoff — while Carvar takes four self-service steps: book, unlock, drive, return. The old way Search Call Negotiate Paperwork Key handoff Carvar Book Unlock Drive Return no calls, no paperwork, no handoff
Four self-service steps replace five manual ones — and the labor floor under the price
  • 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.
Two booking requests arrive for the same car and dates at once. In the application-layer path both read "available", both write, and the lot is empty at 6am — a double-booking. In the database path the same two requests hit a transaction guarded by an exclusion constraint, so exactly one commits and the other is rejected. same car · same dates · two requests at once CHECK IN APP CODE req A req B read "available" both write empty lot, 6am double-booked TXN + EXCLUSION CONSTRAINT req A req B overlap check enforced in DB one commits other rejected exactly one car
In app code, two concurrent checks both see "available" and both write — the 6am empty lot; in the database, a transaction plus an exclusion constraint lets exactly one booking commit and rejects the other
LayerWhy thisWhat it buys the business
Next.js / React Server-rendered, discovery-first frontend Organic search ranking — free marketing for a price-led challenger
PostgreSQL Relational data with constraints and transactions DB-enforced integrity — double-booking is correctness, not a hope
Express A thin, deliberately boring API layer No surprises — attention stays on the product, not the plumbing
Each stack choice traces back to the economics — and what it buys the business

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.
The trapThe disciplineWhat it buys
Price edge resting on cheap manual ops Cost to serve is the strategy A price a competitor can't match without rebuilding
"We'll call you to confirm" at the end Automate end to end, not the easy 80% The labor floor and the friction both gone
Integrity checked in racing app code Put inventory integrity in the database Correctness that can't be raced around
Novel stack stealing focus from the product Choose boring technology Speed and predictability — what a small team competes with
The same marketplace shape recurs: each trap has a discipline, and each discipline buys a structural edge

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.