Society Auto: an auto rickshaw booking app for a private residential society in Gujarat
Society Auto is an auto rickshaw booking app that Yukti AI built in about 7 days for a private residential society in Gujarat: a working app with three connected sides — member booking, a driver app and a society admin dashboard — plus a round-robin driver allocation engine and live tracking. Think of it as a society management app focused on one service, transport: every ride goes to the next driver in line, that driver gets 25 seconds to accept, and the booking moves on by itself.
The society has its own auto-rickshaw drivers and fixed fares to the railway station, the market, GIDC, the bus stand and the hospital. Drivers were called and allotted by hand, so every allotment could end in an argument over whose turn it was. Yukti AI built a closed-community booking system instead: only verified flats can book, the society sets the fare chart, the driver app is designed for drivers who are not comfortable with technology, and the office watches every booking and the driver queue live. The interactive version is public, so anyone can try booking, allocation and tracking on a phone. The rollout for the society covers member and driver apps on Android and iPhone plus a web admin panel with ride OTP.
Quick facts
| Client | A private residential society in Gujarat (not named on this site) |
|---|---|
| Industry | Residential society transport: closed-community auto-rickshaw booking and driver dispatch |
| Users | Members (verified residents), the society's own auto drivers, and the society office (secretary or office clerk) |
| Core challenge | Drivers allotted by hand over the phone; disputes over whose turn it was; no answer when a driver did not respond; nothing to keep outsiders out; no register of bookings |
| Solution | Member booking, a driver app and a society admin dashboard on one live booking record, with a round-robin allocation engine and live tracking |
| Dispatch rule | Next online driver in rotation, 25 seconds to accept, then the next driver; back of the queue after each completed ride |
| Destinations | Railway Station, Market, GIDC, Bus Stand, Hospital, and Other Location (fare decided by the office) |
| Fares | Fixed by the society per destination, shown before booking, no surge pricing |
| Build time | About 7 days |
| Try it | The interactive version is public at society-auto-demo.vercel.app |
| Rollout scope | Member and driver apps for Android and iPhone from one codebase, a web admin panel on a Yukti AI subdomain, member verification by the secretary, and a 4-digit ride OTP |
| Designed as the next step | WhatsApp booking and automated voice-call acceptance for drivers |
What is Society Auto? A closed-community auto rickshaw booking app for one private residential society: verified residents book the society's own autos at the society's fixed fares, and a round-robin engine hands each ride to the drivers in turn.
Can I try it? Yes. Open the public interactive version on a phone, book a ride as a member, accept it as a driver and watch the admin dashboard update. Nothing to install.
Who builds apps like this? Yukti AI, through its app and web app development service in Surat, builds booking apps, dashboards and business systems around each client's own rules.
What members and drivers see
Two screens from the public interactive version of Society Auto, built by Yukti AI. Fares and figures on these screens are sample values, not the society's own chart.
Why does a housing society need its own auto rickshaw booking app?
Because a society's auto service is a small closed network, not an open city market. This society has its own drivers, its own fixed fares and a known list of flats allowed to use the service. What it did not have was a fair, visible way to hand each booking to the next driver, and a record the office could trust. Before Society Auto, all of that ran on phone calls.
Every ride started with phone calls. Drivers were called and allotted manually, one booking at a time.
With no fixed rotation, there was no fair way to share work among the drivers, and any allotment could turn into an argument or a charge of favouritism.
When a driver did not respond, nothing moved the booking on. A member could be left waiting with no answer at all.
Nothing stopped people outside the society from using a service meant only for residents.
There was no check that the right passenger got into the right auto, and nothing to stop a ride being marked complete when it had not happened.
The office had no central record of bookings, driver status, fares or collections, and residents could not see where their auto was.
Why not just use Uber or Ola for the society?
Public ride-hailing apps are built for an open city market: any rider, any nearby driver, and fares set by the platform. A society's service is the opposite. It runs the society's own autos, for verified residents only, at fares the committee fixes, with a turn system that shares rides equally among its drivers. That is why Society Auto is a closed-community booking system rather than an Uber clone.
Taxi booking app development, scaled to one society
A society that asks a taxi booking app development company in India for a quote is usually offered a full ride-hailing clone, the kind of cab booking app built for a whole city: open sign-up, city-scale driver onboarding, dynamic pricing and a marketplace to run. Society Auto keeps only what a closed community needs — verified members, the society's own drivers, a fair rotation, a fixed fare chart and one office view.
- Closed-community ride booking
- A booking service only a defined group can use — here, residents of flats the society office has verified — served only by the society's own drivers.
- Round-robin driver allocation
- Offering each new booking to the next driver in a fixed rotation, rather than to whoever picks up first or to a favourite.
- Acceptance window
- The time one driver has to accept an offer before it moves on: 25 seconds in Society Auto.
- Back-of-queue rotation
- After completing a ride, a driver goes to the end of the line, so work is shared equally.
- Escalation
- When no driver accepts, the booking goes to the society office (rollout scope).
- Ride OTP
- A 4-digit code the member sees when a driver accepts; the driver enters it at pickup to start the ride (rollout scope).
How the society's auto service changes
Each change follows directly from what was built. No usage figures are claimed here: Yukti AI does not publish numbers that have not been measured.
Before
- Drivers called and allotted by hand
- No fixed turn, so “whose turn is it” disputes
- An unanswered call left the member waiting
- Nothing stopped outsiders using the service
- No check that the right passenger boarded
- No central register of bookings, drivers or fares
- No way to see where the auto was
After
- A member books in three taps from the phone
- Next online driver in rotation gets the offer; back of the queue after each ride
- 25 seconds to accept, then the booking moves on by itself
- Only verified flats can book
- A 4-digit ride OTP to start each ride (rollout)
- Admin dashboard, booking register and reports
- A live map with ETA from acceptance to the gate
How are the three sides of Society Auto connected?
All three sides read and write one shared booking. When a member books, the allocation engine offers the ride to a driver, the driver's screen shows a full-screen alert and the admin dashboard shows the booking, all from the same live record. A status change on one screen appears on the other two, so the member, the driver and the office never see different versions of the same ride.
How does a member book an auto in three taps?
By choosing a destination, confirming the pickup flat and tapping BOOK AUTO. The member screen opens on a “Need an Auto?” grid of six destination tiles, each showing the society's fixed fare. The member then picks the pickup building and flat, checks a confirm card with the fare and an estimated arrival of two to five minutes, and books from a button fixed to the bottom of the screen.
Choosing Other Location tells the member that the fare for that trip is decided by the society office. A flat that has not been verified sees: “Sorry, this service is available only to verified society members.”
Finding your auto, in the open
After booking, a “Finding your auto…” screen shows a live driver-queue list, and every offer carries a badge: Calling…, Not available, No response or Accepted. The member watches the system work through the drivers in turn — the reassurance a phone call never gave. When a driver accepts, an “Auto Found!” card shows the driver's name, auto number and ETA, with Call Driver and Cancel Ride buttons, and a seven-step tracker follows the ride:
If every online driver has been tried, the member sees “No auto is available right now” with a TRY AGAIN button, not silence.
How does live tracking show where the auto is?
From the moment a driver accepts, the member sees the auto on a map with an ETA that updates as it moves, a pulsing LIVE badge while location is shared, and a “Your auto has arrived” message when the driver taps ARRIVED. In the public interactive version the route is drawn on a hand-built map and the auto's movement is animated, so it runs in any browser with no map API key. In the rollout, the position comes from the driver's phone, which shares location in the background.
The member app for Android and iPhone adds one-tap Google login (or Apple ID on iPhone), a flat verified once and remembered, the driver's photo, in-app calling, a 4-digit ride OTP, push notifications at every stage, a My Rides history, and a full Gujarati and English interface.
How does round-robin driver allocation decide whose turn it is?
It offers every booking to the next online driver in a fixed rotation, one driver at a time. That driver has 25 seconds to accept. If they reject the ride or the time runs out, the booking moves to the next online driver who has not been tried yet. A driver who completes a ride goes to the back of the queue, so rides are shared equally and nobody has to argue over turns.
The rules the engine applies
- Skip who cannot take it. Offline drivers are skipped, and so is anyone already offered this booking.
- Move on without a phone call. On a reject or timeout the member sees “Contacting the next driver…”, and the next driver is offered the ride 1.5 seconds later.
- No double booking. Accepting sets the driver to “On a ride”, so they get no new offers mid-ride.
- Back of the line. Completing a ride sets the driver back online, adds it to their rides and earnings, and moves them to the back of the queue.
- Never silent. When no online driver is left, the booking becomes “no driver” and the member is told at once; in the rollout it is also escalated to the society office.
Ten booking stages, one record
Every ride is one record moving through ten stages, read by all three sides.
| Stage | What it means |
|---|---|
| idle / searching | No active booking / the engine is offering the ride to drivers in turn |
| assigned / accepted | A driver has been alerted / the driver accepted and the member sees Auto Found |
| on_the_way / arrived | The auto is heading to the society / it is at the member's building |
| in_progress / completed | The ride has started / it is finished and the driver returns to the queue |
| cancelled / no_driver | The ride was cancelled / every online driver was tried and nobody accepted |
Allocation is a deterministic rule, not a machine-learning model, and for a fairness rule that is the right design. The committee can tell every driver why a ride went to someone else, and “next in line, 25 seconds, then the next” is a rule anyone can check on the admin screen.
Can a driver who is not comfortable with technology use the driver app?
Yes — that was the brief. The society's drivers were described as not comfortable with technology, so the driver app has one large online/offline card, extra-large buttons and colour-coded states: green online, red offline, amber for an incoming booking. A new booking takes over the whole screen, so it cannot be missed, and accepting it is one big button.
The home screen is essentially one card — “YOU ARE ONLINE” with a large GO OFFLINE button — above tiles for today's rides, completed rides and earnings. While a booking is offered to someone else, the driver reads: “If they do not answer, it will come to you automatically.” That one line explains the rotation better than a rule book.
The incoming booking alert
A new booking opens a full-screen amber NEW BOOKING alert with the pickup building, destination, fare and distance. A 25-second countdown bar turns red in the last 8 seconds, ACCEPT BOOKING is the biggest thing on the screen, and in the second version a chime rings every 5 seconds. After accepting, the ride buttons appear one at a time — ARRIVED, START RIDE, COMPLETE RIDE — so there is never a wrong button to press. In the second version, labels also carry Gujarati, such as “GO ONLINE NOW (ડ્યુટી શરૂ કરો)”.
Driver accounts are created by the office. The alert rings and vibrates even on a locked phone, one tap opens Google Maps to the pickup point, location is shared in the background, and the ride steps become Arrived → OTP entry → Start Ride → Complete Ride. Drivers also get Gujarati throughout in large text, a leave mode and weekly and monthly earnings.
What does the society office see on the admin dashboard?
The whole service on one screen: today's bookings, active drivers out of the total, completed and pending rides and the day's collection; a Live Driver Status table with each driver's status, current ride and queue position; and a Driver Allocation Queue panel that shows who is next. The secretary or office clerk never has to phone anyone to know what is happening.
Eight sections, one sidebar
| Section | What the office does there |
|---|---|
| Dashboard | Today's KPIs, live driver status, the allocation queue and recent bookings |
| Bookings | A searchable register: ID, member, pickup, destination, driver, fare, status, time |
| Drivers | Set a driver online or offline, edit details, add a driver |
| Members | Search by name, flat or mobile; Verified or Pending verification badges; add or import members |
| Fare Settings | The society's fixed fare per destination; new bookings use the new rate |
| Live Map | The ride in progress |
| Reports | A rides-by-hour chart and a busiest-time insight |
| Settings | The 25-second driver timeout, automatic rotation, and “Only verified flats can book” |
The web admin panel opens in a laptop or mobile browser on a Yukti AI subdomain. It adds approve, block or remove for members, building-wise and flat-wise; driver records with auto number, photo, documents and contact; reports by date, building, driver and destination, exportable to Excel; and a complaint and feedback register.
How are outsiders kept out, and how is each ride verified?
Two controls do it. First, only verified flats can book: the interactive version already turns away a flat that is not verified, and in the rollout a resident signs in, enters their building and flat, and booking unlocks only after the secretary approves the request. Second, in the rollout every ride carries a 4-digit OTP: the member sees it when a driver accepts, and the driver must enter it at pickup before the ride can start, so an auto never leaves with the wrong passenger.
Member verification in the rollout
Ride OTP in the rollout
Without the OTP, a ride cannot be started or falsely marked complete. If the member's phone is switched off, the driver taps “OTP not received” and the society office starts the ride manually. The rollout also creates driver accounts only from the office, gives role-based access for admin, office staff and driver, runs the admin panel over SSL, and keeps the member and ride data owned by the society and exportable.
An SOS button, sharing a trip with family, and scheduled rides for school, office or station runs are not part of this scope. They fit the same booking record and can be quoted as additions.
Why build a working version before the committee decides?
Because a housing society committee decides together, and most of its members will never read a software proposal. So before sending one, Yukti AI built the whole booking journey and put it online, where the committee could try it on a phone with nothing to install: book as a member, accept as a driver, and watch the admin dashboard update, all on the same live booking.
A one-click PLAY DEMO BOOKING button runs the whole story in ten steps, from booking and the driver alert to tracking, completion and the admin update. Demo Controls step through it by hand, including Driver Reject and Simulate Timeout, and tabs switch between MEMBER, DRIVER, ADMIN and HOW IT WORKS. A second version adds a side-by-side mode for committee meetings, with the member phone, the driver phone and the admin view updating together. A full walkthrough takes about five to ten minutes.
Can members book on WhatsApp, and can drivers accept with a phone call?
Both are designed as the next step. The interactive version includes a WhatsApp booking screen and an automated voice-call screen for drivers, clearly shown as concept screens; neither is connected to WhatsApp or a phone line today. Both were deliberately left out of the core scope, which keeps the base system simple and free of recurring messaging costs.
WhatsApp booking
The member sends “Hi”, taps a destination button, chooses the pickup building, and receives the driver's name, auto number, ETA and a Track Auto link — booking without installing anything.
Voice-call acceptance
An automated call reads the booking to the driver in Gujarati: press 1 to accept, press 2 to reject. A driver who does not have the app open can still take the ride.
SMS and payments
SMS alerts, an online fare payment gateway and billing through the maintenance bill were also kept out of the core scope, and can be quoted later.
Both use channels Yukti AI already builds with: WhatsApp automation on the official WhatsApp Cloud API, and automated calling through voice AI agents. Because every booking is already one record with clear stages, a WhatsApp message or a press-1 call is just another way to create or accept it.
What is built, what is in the rollout, and what comes next
| Capability | Status |
|---|---|
| Member booking, driver app and society admin dashboard on one live booking record | Built; the interactive version is public |
| Round-robin allocation, 25-second offer, back-of-queue rotation, no-driver handling | Built |
| Live tracking with ETA | Built; the route is animated in the interactive version and comes from the driver's phone in the rollout |
| Member and driver apps for Android and iPhone, Google and Apple sign-in, member approval | Rollout scope |
| Ride OTP, push notifications, background location, Excel reports, complaint register | Rollout scope |
| WhatsApp booking and automated voice-call acceptance for drivers | Designed as the next step |
| SMS, online payment, maintenance-bill billing, scheduled rides, SOS | Not in scope; can be added |
Who sets the fare, and how is the ride paid for?
The society sets the fare. Each destination has a fixed fare in the society's fare chart, the member sees it before confirming, and there is no surge pricing. There is no in-app payment in this scope: the fare is paid to the driver by cash or UPI (the second version's driver screen shows a “Collect Cash/UPI” prompt), and the admin dashboard totals the day's collection. When the office edits a fare in Fare Settings, every new booking uses the new rate; for Other Location, the office decides the fare.
| Payment model | How it works | In this build? |
|---|---|---|
| Per ride, paid to the driver | Fixed fare shown before booking; collected by cash or UPI | Yes, outside the app; the second version prompts “Collect Cash/UPI” |
| Online, in the app | The member pays through a payment gateway | Not in scope; can be added |
| Monthly, through the society | Ride charges added to each flat's maintenance bill | Marked as a possible Phase 2 |
| Society-funded or prepaid | The society or the member pays in advance | An option, not built |
How was Society Auto built in about 7 days?
By starting from the society's rules and building the software around them: who may book, where they go, what each trip costs, and how a ride passes from driver to driver. Those rules shaped one booking record with ten stages, and the member, driver and admin sides were built on that single record, so the three screens could never disagree.
The society's rules
Destinations and fixed fares, verified flats only, the society's own drivers, and a rotation that shares rides equally.
One booking record
A ten-stage booking model and one shared live state that all three sides read and write.
The allocation engine
The rotation, the 25-second offer, reject and timeout handling, the no-driver state and back-of-queue rotation.
Three sides and tracking
Mobile-first member and driver screens, a desktop-first admin dashboard, and the live map with an updating ETA.
Walkthrough, then rollout
The interactive version deployed for the committee. The rollout scope adds the Android and iPhone apps, the web admin panel with ride OTP, society branding, a pilot inside the society, in-person training, Gujarati guides and 12 months of support after go-live.
What technology runs Society Auto?
The interactive version is a Next.js 14 and React 18 app written in TypeScript, styled with Tailwind CSS and hosted on Vercel. All three sides share one state, the admin chart uses Recharts, and the map is hand-built so it needs no map API key. The rollout moves that shared state to a cloud database with a real-time engine, so a status change shows instantly on all three screens.
Mobile app development from Surat, built to keep running costs low
The rollout builds the Android and iPhone apps from a single codebase and avoids the paid pieces many apps lean on: free Google and Apple sign-in instead of paid SMS OTP, free push notifications, and the admin panel on a Yukti AI subdomain, so the society does not need to buy a domain.
Full technical detail
- Next.js 14 (App Router), React 18, TypeScript 5, Tailwind CSS 3.4 — member, driver and admin sides in one codebase; mobile-first phones, desktop-first admin.
- React Context — one shared store for all three roles, so switching tabs mid-ride shows the same booking.
- Allocation engine — a rotating queue pointer, a 25-second offer window on a 500 ms master ticker, and a 1.5-second hand-off to the next driver.
- Hand-built SVG map, Recharts, Web Audio API — animated route legs with a recomputed ETA, the rides-by-hour chart, and the driver's ringing chime (second version).
- Proposed production mapping — the technical plan maps the rollout onto managed Postgres with real-time updates and auth (Supabase is proposed), a server-side function for the queue and 25-second timer, Firebase Cloud Messaging for push, and Google Maps or Mapbox.
How much does a society auto booking app cost, and how long does it take?
Yukti AI quotes a fixed price for a society booking app after a free workflow audit, as a one-time build rather than a per-booking or per-member subscription. Society Auto itself was built in about 7 days. The final quote depends on how many apps and platforms you need, the languages, the verification and OTP rules, the reports, and whether WhatsApp, voice calls or payments are included.
| What moves the quote | What it covers |
|---|---|
| Apps and platforms | Member and driver apps for Android and iPhone, plus the web admin panel |
| Language | Gujarati and English throughout, with large-text driver screens |
| Rules and safety | Offer timing, escalation, leave mode, flat approval, ride OTP, role-based access |
| Reports | Date-, building-, driver- and destination-wise reports with Excel export |
| Add-ons | WhatsApp booking, automated voice calls, SMS, online payment, maintenance-bill billing |
| Launch and support | Society branding, a pilot, in-person training, Gujarati guides and 12 months of support |
There is no charge per member or per booking. After the included 12 months of support, an annual maintenance charge applies from the second year, and Apple's yearly developer fee applies to the iPhone apps. Every amount is set out in the written proposal after the audit.
An app development company in Surat: who else is this for?
Yukti AI is a software company at 220, Leonard Square, Yogichowk, Varachha, Surat, building custom apps, web apps and business systems for clients across Gujarat and India. Society Auto is one of several builds delivered in about a week, alongside a diamond trading platform for a Surat export house and tour operator software for a three-company travel group. Other Surat work includes a jewellery ERP and CRM for Lumera Fine Jewellery and a business management system for Maven Lift.
The closed-community booking pattern fits anywhere a fixed group shares a fixed fleet:
- Gated societies and townships that run their own autos, e-rickshaws or shuttles
- Campuses, hostels and corporate parks with staff or student transport
- Industrial estates, such as GIDC units, that run pick-up and drop for workers
- Residents' associations that want one service app now, before a full society management app
Start with a free workflow audit, or see Yukti AI's app and web app development in Surat, real estate automation and the full AI-powered business management system.
Questions societies ask about an auto booking app
Explore more
App & Web App Development in Surat
Custom apps, web apps, dashboards and ordering systems, built around the way your organisation actually works.
Real Estate
AI automation for real estate brokers and developers: WhatsApp lead qualification, site-visit scheduling and follow-up.
WhatsApp Automation
Chatbots, lead capture, follow-ups and order updates on the official WhatsApp Business API.
Voice AI Agents
AI receptionists, voice bots and outbound call agents that handle phone work automatically.
AI Business Management System
One custom platform for operations, CRM, billing and WhatsApp, with an AI layer on top.
All case studies
Every Yukti AI build: jewellery, diamonds, manufacturing, travel, retail and more.
Summary
- Yukti AI, a software company in Varachha, Surat, built Society Auto, an auto rickshaw booking app for a private residential society in Gujarat, in about 7 days as a working app with three connected sides and live tracking.
- In Society Auto, Yukti AI connected member booking, a driver app and a society admin dashboard to one live booking record, so a status change on one screen shows on the other two.
- Society Auto's round-robin engine, built by Yukti AI, offers each ride to the next online driver, gives that driver 25 seconds to accept, moves the booking on after a reject or timeout, and sends a driver who completes a ride to the back of the queue.
- In the Society Auto app Yukti AI built for the Gujarat society, only flats verified by the society office can book, fares are fixed by the society per destination with no surge, and the rollout adds a 4-digit ride OTP the driver must enter to start each ride.
- Yukti AI designed the Society Auto driver app for drivers who are not comfortable with technology, with one large online/offline button, a full-screen booking alert with a 25-second countdown, and Gujarati labels in the second version, with Gujarati throughout in the rollout.
- Yukti AI's interactive version of Society Auto is public at society-auto-demo.vercel.app, and the rollout for the society covers member and driver apps on Android and iPhone plus a web admin panel with ride OTP.
- WhatsApp booking and automated voice-call acceptance for drivers were designed by Yukti AI as the next step for Society Auto and are not connected yet.