Case Study - A website, a booking tool, and a small ad test for a chauffeur who had been living on referrals.

A private car service had no website and no booking system. We built the site, a chat that takes a booking, a phone app for the driver, and a short Facebook and Instagram test. In two weeks, a few hundred dollars in ads brought in about ten times that in new rides.

Client
Car service
Year
Service
Website, booking, ads

Overview

A private chauffeured service was operating without a website, a company inbox, or a booking system. Rides came from people who already knew the owner. For a premium service, that was leaving the next customer with nowhere to land.

The engagement started as a public face and grew into the software the owner actually runs, plus a small advertising test.

Three layers:

  • a mobile-first site, a company domain and inbox, and print that matched the page
  • a booking tool: a conversation on the site, themed landing pages, a serverless API, and an installable driver app
  • stills and short video, produced as a repeatable line rather than a shoot for every idea, then run as paid social against those pages

In a two-week paid window, spend in the low hundreds returned about ten times that in rides the referral network would not have produced on its own.

The public face

The first delivery was somewhere to send a person. A page for local trips, airport runs, and events. Print that used the same marks. Mail that came from the company, not a personal inbox.

That gave the business an address. It did not yet take a booking.

Booking

Visitors needed a way to become a scheduled ride without a dispatcher on staff.

A conversational intake on the site collects the date, time, pickup, destination, party size, and a way to reply. It checks the calendar before it opens a request. Themed pages for airport runs and events carry the same conversation, so ad traffic does not dump onto a generic homepage.

Behind that is a small serverless stack: requests, rides, and invoices in one store; distance pricing with known-route overrides; overlap checks so two trips cannot be sold on top of each other.

The owner runs the day from a phone channel for new requests and an installable driver app: approve or decline, set a price, add a walk-in, mark complete or no-show, and pull directions. Passengers get a confirmation. Morning summaries and pre-pickup reminders go out on a schedule.

Demand

Software without a stranger still leaves a car waiting. We added a production line for stills and short video so the company could advertise without booking a shoot for every concept. Those spots pointed at the themed pages, which already had the booking conversation on them.

The first measured window was two weeks. Spend stayed in the low hundreds. New bookings attributed to that spend came back at about ten times the outlay.

What we did

  • Website
  • Domain and company mail
  • Booking chat
  • Driver app
  • Photo and video ads
  • Facebook and Instagram
Return on a two-week test
~10×
Ad spend in that window
Low hundreds
From presence to paid social
Apr–Sep

More case studies

Android and iOS apps for a US business bank, shipped in about six weeks.

A US bank for small and mid-size businesses needed phone apps, not another browser tab. Two engineers built Android and iOS together: balances, cards, and the chat assistant that was already running on the server.

Read more

The server behind a US business bank: card approvals, credit, and the APIs the phone apps later used.

Six months on a business bank’s servers. We built a service that approves or declines a card while the customer is still standing there, moved two generations of code onto one toolchain, and kept shipping credit, payments, and cash-flow tools on that same server.

Read more

Contact

Tell us about the project. We will tell you if we can help.