RYVEO

Ride-hailing app for Saudi Arabia: requirements, documentation and design

We gathered the requirements for RYVEO, wrote the full documentation set, and designed every screen, so a development team could start building with nothing left to guess.

Book an intro call See the deliverables

Product name and branding changed to protect client confidentiality. Our role: discovery, requirements, documentation and design. We did not build it.

Booking screen with pickup, destination, and fare

Screens designed: 109
Platform: iOS and Android
Market: Saudi Arabia
User roles specified: 2

Overview

RYVEO is a ride-hailing app planned for Saudi Arabia. The client came to us with a strong idea and a market they knew well. We turned that idea into a product a development team can build: documented business goals, detailed functional behavior, a technical architecture, a data model, and a complete app design.

The app serves riders and drivers in one product, prices trips in Saudi riyals, works in English and Arabic, and connects riders to local emergency services during a trip.

What made it complex

The client had the idea and deep knowledge of the Saudi market. What was missing was a precise, shared definition of the product: one that development vendors could quote against accurately and engineers could build from without guesswork.

Turn a broad idea into scoped, testable requirements
Define fare negotiation rules that feel fair to riders and drivers
Specify two user roles that share one app
Account for local expectations: riyal pricing, Arabic, emergency numbers, and driver gender preference
Produce documentation complete enough for any vendor to estimate and build

Key decisions we made

Two or three decisions and whyFor example, a rule you simplified, a feature you cut from version one, or a trade-off the client accepted.

What the product does

Every feature below was specified in the requirements and shown in the designs.

Fare negotiation. Riders propose a price, and drivers accept or counter in quick fixed steps.
Live trip tracking. Pickup time, driver location, and route on a single screen.
Scheduled rides. Book for a later date and time, with auto-accept for offers under a set fare.
Driver request queue. Drivers see distance, rating, and fare for each nearby request before accepting.
In-app chat and calls. Riders and drivers message, call, or video call from the trip screen.
Safety center. One-tap calls to ambulance (997) and police (999) during a trip.
Identity verification. Face and fingerprint sign-in for faster, more secure access.
Promotions. Promo codes and time-limited discounts applied before booking.
Ride history and disputes. Past trips with fare breakdowns, cancellation reasons, and dispute status.
Wallet and payouts. Riyal balance, earnings, and linked Saudi bank accounts for drivers.
Driver gender preference. Riders can choose who picks them up.
English and Arabic. Switch between English and Arabic at any time from settings.

How we worked

Discovery sessions, then business, functional and technical requirements and a data model, then design and handover. Every screen traces back to a documented requirement.

The same process, as a service

What the client received

Plain names first; the short labels are what developers call each document.

BRD

Business Requirements Document

Business goals, market context, user groups, scope, and success measures.

FSD

Functional Specification Document

Every feature, user flow, business rule, and screen behavior for riders and drivers.

TRD

Technical Requirements Document

System architecture, integrations, security, performance, and hosting requirements.

ERD

Entity Relationship Diagram

The data model: riders, drivers, vehicles, trips, fare offers, payments, and how they connect.

User stories

Stories and acceptance criteria

Each requirement broken into buildable, testable units for the development team.

API spec

API specification

The endpoints and data contracts between the mobile app and the backend.

App design

UX and UI design

109 screens covering sign-up, booking, trips, payments, safety, and support.

Pitch deck, if deliveredAdd as a deliverable where you prepared one for this client.

A look inside the product

8 of the 109 screens we designed. Scroll or swipe to see more.

Technology specified

Stack from the technical requirementsMobile framework, backend, database, maps, payments, SMS and hosting. Publish only what the client allows.

Outcome

What happened nextOne true sentence, for example: the client selected a development partner, raised investment, or started the build. Remove this block if it cannot be shared.

109Screens designed

2User roles specified

Content needed: a real quote from this client, two or three sentences, in their own words

Content needed: role, company type and country (name optional)

Have a product like this in mind?

We start with discovery: requirements, documentation and design that any development team can quote and build from.

Book an intro call

Free and without obligation. Content needed: call length

Before the callWe read what you sent, so the call starts with your problem.
On the callWe ask questions, listen, and explain how we would approach it.
After the callIf we are a fit, a written proposal with a fixed scope follows. If not, we say so.