Describe a ride-sharing app and Fastshot builds it. Riders request a trip, drivers accept it, and both phones update the moment the status changes. Real React Native code for iOS and Android, ready to try in about 5 to 7 minutes.
Write one prompt that describes a rider flow and a driver flow. Fastshot (fastshot.ai) builds a React Native app with a ride requests table in Supabase, and every status change reaches both phones through realtime. You scan a QR code to test it in Expo Go. Start with one city as an MVP, then add vehicle types and a second market.
Last updated: November 4, 2026
Uber matches riders with nearby drivers. A rider types a destination into the Where to? box, confirms the pickup spot and is matched to a driver. They follow the driver on a map, check the plate, car model and driver photo, and rate the trip afterwards. Price estimates appear before the rider confirms.
Drivers use a separate Driver app. They tap Go to start receiving requests. Each request shows a fare estimate, the rider rating and the trip length, and it times out if the driver does nothing. Ratings run both ways, so a rider is judged as well as a driver.
Three ideas carry the product: a request that moves through clear states, a live view of where the other person is, and trust built from profiles and ratings. Those are what a ride-sharing clone copies. Uber also reserves rides up to 90 days ahead and runs in more than 10,000 cities, but a first taxi app for one town needs none of that scale.
Each Uber behavior becomes a screen in your app and a table or bucket in Supabase.
| Uber feature | How it ships in your app | What it stores |
|---|---|---|
| Where to? destination box | Request Ride screen with pickup and drop-off fields and a map screen built on react-native-maps | rides: rider_id, pickup_text, dropoff_text, pickup_lat, pickup_lng, dropoff_lat, dropoff_lng |
| Matching with a nearby driver | Driver Home screen with an Online switch and a live list of open requests; the first Accept wins | drivers: is_online; rides.driver_id filled on accept |
| Follow your driver on the map | Active Trip screen with a moving driver pin that refreshes through Supabase realtime | drivers: lat, lng, updated_at |
| Driver, car and plate check | Driver card shown to the rider after acceptance, with photo, car model and plate | vehicles: make, model, plate; profiles.avatar_path in an image storage bucket |
| Trip stages | A status strip on both screens: requested, accepted, arrived, in progress, completed, cancelled | rides.status and rides.updated_at |
| Rate your trip | Rating screen for both roles after completion | ratings: ride_id, from_user, to_user, stars, comment |
| Reserve a ride in advance | Schedule toggle with a date and time picker on the request form | rides.scheduled_for |
| Trip history | History tab for riders and a Completed Trips list for drivers | The same rides table, filtered by rider_id or driver_id |
Fastshot plans these screens before it writes code, and you approve the list first.
Email, Google or Apple sign-in through Supabase auth, then a Rider or Driver choice saved on the profile.
Pickup and drop-off fields over a map, an optional schedule switch and a big Request button.
A waiting state that listens for the accept event and offers a Cancel button while the request is open.
The driver pin, the status strip and the driver card for the rider, and Arrived, Start and Complete buttons for the driver.
An Online switch and a live list of open requests with pickup and drop-off text.
One to five stars and a short comment, shown to both sides when the ride completes.
Past rides for each role, plus a profile with a photo upload and, for drivers, the vehicle details.
It builds an original ride-sharing app called HopRide with its own name and look. Rename it before you publish.
Build a ride-sharing app called HopRide for iOS and Android. One app, two modes: at sign-up the user picks Rider or Driver.
Auth: email, Google and Apple sign-in with Supabase. Save the choice in a profiles table (full_name, role, avatar_path).
Rider screens
- Request Ride: pickup and drop-off fields, a map, an optional "schedule for later" switch.
- Finding Driver: waiting state with a Cancel button.
- Active Trip: driver pin on the map, driver name, car model, plate and a status strip.
- Rate Trip: 1 to 5 stars and a comment.
- History.
Driver screens
- Home: Online switch and a live list of open requests.
- Active Trip: buttons Arrived, Start Trip, Complete Trip.
- Completed Trips list.
Tables: rides (rider_id, driver_id, pickup_text, dropoff_text, pickup_lat, pickup_lng, status, scheduled_for, created_at), drivers (user_id, is_online, lat, lng, updated_at), vehicles (driver_id, make, model, plate), ratings (ride_id, from_user, to_user, stars, comment).
Statuses: requested, accepted, arrived, in_progress, completed, cancelled.
Use Supabase realtime on rides and drivers so both phones update with no refresh. Row level security: a rider reads only their rides; a driver reads open requests and the rides they accepted.
Send a push notification to the rider when a driver accepts and when the driver arrives.
Design: clean, dark map, green accent, large tap targets.Fastshot asks one or two questions, for example whether you want one vehicle type or several. It then writes a plan of screens that you approve before any code appears.
Press the connect button in the chat. Fastshot creates the rides, drivers, vehicles and ratings tables and turns on realtime for rides and drivers. The backend lesson walks through the same step.
Open the app in Expo Go through the QR code and sign up as a rider. Open the live browser preview, or a second phone, and sign up as a driver. Request a trip on one screen and watch it land on the other.
Ask for push notifications when a driver accepts and arrives. The rider no longer needs to keep the screen open.
Ask for a bike or van option, a scheduled-ride picker or a longer rating comment. Each request is a follow-up message, and the app rebuilds in the preview.
Fastshot builds the APK, AAB and IPA on its own machines. Add your Apple Developer account for TestFlight and your Google Play account for Android, as the Google Play lesson shows.
A clone of a global giant loses to the original. A ride app aimed at one group wins that group. Think of school runs for parents, campus rides after dark, airport shuttles on fixed routes, motorbike taxis for a town the big apps skip, or accessible rides for wheelchair users. The community already built motorbike and small-town taxi apps on Fastshot, so the pattern is proven.
Then add what the original does not offer your audience: a local language, fixed-route tickets, a favorite-driver list, or a courier mode that reuses the same request flow for parcels and food. Pair it with a restaurant delivery app pattern if drivers carry orders as well as people.
Finally, brand it. Pick a new name, ask Fastshot for an icon and a color palette, and write your own store description. A distinct product is easier to rank in the stores and avoids confusion with the original.
Published community apps in the ride-hailing space. Open one to see the screens.
A ride-hailing app with a map screen, destination search, home and work shortcuts, and a choice of vehicle types. See TAXI in the gallery.
A map-first ride-sharing app with vehicle tracking, saved shortcuts for frequent trips and an activity history. See Ridego in the gallery.
A motorbike-hailing app where riders pass an approval check before they can take passengers. See Rydelink in the gallery.
It means building the software that connects people who need a trip with drivers who can take it. The core is a ride requests table, a driver availability flag and live status updates on both screens. Fastshot generates all three from a text description, so you skip writing the backend by hand.
The first version of a taxi app appears in about 5 to 7 minutes after you approve the plan. Refining the request form, the driver screens and the trip states takes a few more chat messages. Traditional taxi app development with separate rider and driver apps usually runs for months.
No. Fastshot builds one app per project, so the prompt asks for a role picker at sign-up: Rider or Driver. Each role sees its own tabs, and a single profiles table stores the choice. One store listing is simpler to publish and to keep updated.
The app subscribes to the rides table with Supabase realtime. When a rider inserts a request with the status requested, every online driver sees it appear in the list. The first driver to tap Accept writes their id into the row, and the rider screen switches to the active trip.
Yes. Fastshot builds the app on its own build machines and produces the APK, AAB and IPA files. You publish with your own Apple Developer account ($99 a year) and Google Play account ($25 one-time), and Fastshot uploads the build to TestFlight and Google Play for you.
Yes. The project is real React Native and Expo code. You can download it as a zip or push it to GitHub whenever you like, so a developer can extend the app later.
The idea of connecting riders with drivers is open to everyone. Uber owns its name, logo, designs and code, so give your app its own name, icon and look. Transport rules differ by city, so check the licensing a driver needs where you operate.
See how Fastshot turns a prompt into a React Native and Expo project you own.
Tell a rider the moment a driver accepts the trip or pulls up outside.
The same request, courier and status pattern, applied to food orders.
Another two-sided marketplace: hosts, guests and a booking that changes state.
Use Cases
Use Cases
Native Development
Paste the prompt, approve the plan and request your first test ride on your own phone.