Use cases

Build a rides app

Requests, assigned drivers, pricing per route and tracking, with separate sign-up for passengers and drivers.

Everyone searching for this pictures Uber, and the app most people actually need is not Uber. Nearly every real case is transport with a known relationship: school runs, corporate shuttles, neighbourhood vans, small-town taxis, airport transfers. Those do not need a live auction between nearby drivers; they need a request, an assigned driver, a fixed route and recurring billing, and that is what can genuinely be built here.

People reach this page looking for

  • how to build an app like Uber
  • ride booking app builder
  • school transport app
  • shuttle and transfer booking app

What gets built

Four things you could have working this week

Not a feature list. These are the apps people actually describe, and what the platform hands back when they do.

01

Two sign-ups, with separate roles

Passengers and drivers use the same app and see different screens, because the role is a rule in the database rather than a condition in a screen.

02

A request with origin, destination and time

The passenger asks, you or a rule assigns a driver, and the driver accepts or declines. Every state change is a record, so there is a history of what happened.

03

Pricing per route, per distance or monthly

A route table, a rate per kilometre, or a monthly plan for school runs and shuttles, billed as a subscription by card.

04

Tracking and a receipt

The passenger sees the state of the ride and gets a push on confirmation and arrival; a receipt is left behind, which is what a contracting company asks for at month end.

Included

The parts nobody wants to build twice

Database, login, payments and publishing are part of the platform, not a list of services you go and wire up afterwards.

A real database, not a form dump

Every screen reads and writes models you can open, query and export. The data is a database of yours from the first minute, not a spreadsheet the app pretends to read.

Login for your own users

Email, magic link and Google sign-in, with roles and per-record ownership enforced by Postgres itself. A badly written screen cannot become a leak, because the database answers empty.

Payments that land in your account

Stripe, Pagar.me and Mercado Pago connect once. Card, Pix, boleto and subscriptions, with the card fields rendered by a hosted vault your app never touches.

Web, installable, and in the stores

One project published three ways: your own domain, an icon on the phone straight from the browser, and a signed binary submitted under your own store account.

Found in search, and by the models

Titles, metadata, sitemap, structured data and social images are generated with the app. Pages get found instead of only being linked.

React code you can take with you

Real React, edited line by line or by clicking the element on screen, exported as a ZIP or pushed to your GitHub. No lock-in you have to negotiate your way out of.

How it works

From a paragraph to a published app

Three steps, and the second one is the one people do not believe until they watch it.

Describe it in plain language

Say what the app does and what it has to remember. No diagram, no schema, no naming a single framework.

Watch it get built

Screens, data models, login and payments appear while you read. Anything you do not like, you say so and it changes.

Publish, then keep changing it

Live on your domain in seconds, with version history behind you. Tuesday's conversation is Tuesday's release.

Start here

A prompt you can paste right now

This is a complete first message, not a slogan. Paste it, change the nouns to yours, and you have an app to react to instead of a blank page.

Build a school transport app. Guardians sign up and register students with address, school and shift; drivers have their own sign-up with vehicle and capacity; each student is tied to a route and a driver; the guardian sees their child's route, marks an absence for the day and gets a push when pickup and drop-off are confirmed; the driver sees only their own route's list, in stop order, and confirms each pickup; the monthly fee is a card subscription with payment history; and I see a dashboard with routes, occupancy per route, absences for the week and overdue accounts.

Ready to start from

Templates in this category

A template is a working app with data already in it. Open one, make it yours, publish it under your own account.

Tessera

Booking

Class booking for a studio with a hard capacity: credits, a waiting list that moves itself, and a door roster that records who came.

15 screens

Serenity

Booking

A salon diary where every appointment reserves the turnaround, so a gap on the board is time that can really be sold — and an assistant that says which gaps are worth a call.

16 screens

Questions

Frequently asked questions

You can build the part that decides: requests, driver assignment, ride states, pricing and payment. What you cannot build is the real-time contest between nearby drivers with a position updating on the map every second, which depends on continuous tracking and is where the cost of such an app actually sits. For transport with a known relationship that is no loss; for an open marketplace of rides, it is.

Describe it. See it running. Publish it to the store.

Free to start, no credit card. You only pay when you want to publish under your own brand, and you take the code with you if you ever want to.

Build this app freeUse cases