Amir Ventures is a complete transportation mobility platform for running a fleet. It's made of three parts that work as one system: a driver app ("Amir Ventures Car") on iOS and Android, a dispatcher command center ("Amir Ventures Dispatch") on iOS, Android, iPad, and Mac, and a serverless cloud backend that keeps everything in sync in real time. It replaces the phone calls, group texts, and hand-written notes most fleets still run on with one live system for dispatch, tracking, messaging, and settlement.

It's real and in daily production. The platform runs live for an actual transportation company with 30+ active drivers and 4 dispatchers, under a signed licensing agreement. It's roughly 44,400 lines of production code, 53 Cloud Functions, and 25 application screens across the two apps — hardened by real dispatch through rush hours, dead zones, and edge cases you only find in the field.

44,400+ lines of production code, 53 Cloud Functions handling dispatch, notifications, timeouts and audit, and 25 application screens across the driver and dispatcher apps. The interface ships in three languages — English, Russian, and Uzbek.

Real-time GPS with geofenced zones, one-tap dispatch, smart routing to busy drivers ("Together / Next"), scheduled and recurring reservations plus round trips and hourly jobs on a real calendar, two-way messaging with voice notes and photos, automated per-driver commission with OCR payment verification, weekly settlement with correct cash-vs-card math, reports and earnings and leaderboards, an auto-built client database, offline hardening, a black-box audit trail with one-tap restore, and broadcast dispatch. Each of these is covered in its own question below.

Transportation and car-service companies that dispatch their own drivers — the kind of operation that today runs on phone calls, a whiteboard, and a spreadsheet. It's designed for fleets that want the control and visibility of a real system without building software from scratch.

Yes. Dispatchers get trip logs, per-driver earnings, commission breakdowns, and leaderboards. Every completed trip also feeds a client database that's built automatically from your own history — phone numbers, trip counts, and addresses — which you can multi-select and export to CSV for follow-ups and bulk texting.

Yes. There's a fully interactive, click-through recreation of both apps on this site — real screens and realistic data, nothing to install. Tap through the driver flow and the dispatcher center exactly as your team would, then book a live demo to see it running against your operation.

A dispatcher enters the pickup, drop-off, fare, and payment type, then sees the drivers who fit — with live status, zone, and distance — and sends the job with one tap. The driver gets a push offer with a countdown timer; they accept or decline. If nobody takes it in time, the job is surfaced back to the dispatcher to reassign, so it never quietly disappears.

The offer has a timer. If it times out or is declined, the job flips to a "needs a driver" state and comes back to the dispatcher — visible and reassignable — instead of vanishing. This is enforced server-side by Cloud Functions so it works even if the dispatcher's screen was closed.

Yes — that's the smart queue routing. When a driver is mid-trip you can queue the next job to them as "Together" or "Next," so it lands in their up-next queue rather than getting lost. The driver sees exactly what's coming after the current trip, which cuts down the "where's my next one?" calls.

Yes. Broadcast dispatch offers a job to a group of eligible drivers and assigns it to whoever accepts first, then withdraws it from the rest. It's useful for open runs where you just need the nearest available driver to grab it.

Yes. The dispatcher map shows every vehicle live, color-coded by status — online, on trip, available, offline — over your geofenced zones. Active jobs show ETAs so a dispatcher can answer "how far out is my car?" without calling the driver.

Yes. The live production fleet runs with 4 dispatchers working concurrently. Everything is event-driven and syncs in real time, so a job one dispatcher sends immediately reflects on every other dispatcher's screen.

Jobs carry stable identifiers and dispatch state lives server-side, so re-assigning or recovering a job reuses its record rather than spawning a duplicate. There's also a server-side dedup guard and a full audit trail, so if anything looks off a dispatcher can see exactly what happened to a job and restore it.

It turns a driver's phone into a live dispatch terminal. They go online, receive job offers with fare and pickup details, accept with one tap, follow a simple start-to-finish trip flow, chat with dispatch, see their queued up-next jobs, and track their own earnings and commission — all in their language.

Through push notifications engineered as Time-Sensitive alerts, so they break through Do-Not-Disturb and Focus modes. This matters in the real world: many phones enable a Driving Focus while in the car, which would otherwise silence a normal push. Time-Sensitive delivery with higher priority gets the offer in front of the driver.

A driver signs in with their phone number and a PIN, and can enable Face ID or Touch ID for fast re-entry. They set their vehicle and payout details, pick a language, and they're ready to receive jobs. The app is deliberately simple so onboarding a new driver takes minutes, and printable step-by-step driver guides exist in all three languages.

Yes. Each driver has an earnings screen with take-home after tolls, a daily breakdown, trip count, and their current commission rate. They also see commission owed for the week and can pay it in-app and upload proof — the platform handles verification.

Yes. A driver can back out of a job that hasn't started, which returns it to the dispatcher for reassignment. Because dispatch state is server-side, the release and re-offer flow is clean — the job goes back into circulation rather than sitting stranded.

No. Location is captured in both the foreground and background, and job offers arrive as push notifications, so a driver still gets pinged and stays on the map even when the app isn't front-and-center. There's also an idle safeguard that gently sets a long-idle online driver back to offline so the board stays accurate.

The driver app streams location — foreground and background — to the backend, and dispatchers see it live on the map. It also feeds ETAs and the geofenced-zone logic. If a driver briefly loses signal, there's offline GPS recovery so their position isn't dropped the moment they hit a dead zone.

Zones are geographic areas on the map. A driver's zone can be detected from their GPS position, which helps a dispatcher route the right job to the right area and see availability by zone. It keeps dispatching organized around real geography instead of guesswork.

Yes. Jobs can be scheduled for a specific future time and land on a real calendar. Scheduled reservations show on the dispatcher's Scheduled tab and are assigned to drivers ahead of time or held for assignment as the time approaches.

Yes. Recurring bookings — like a daily school run or a weekday airport shuttle — are set once and auto-generated on schedule by a Cloud Function, so a dispatcher isn't re-entering the same trip every morning.

Yes to both. Round trips carry a return leg with its own drop-off step, and hourly jobs are supported as a distinct trip type. They're tagged clearly on the cards so drivers and dispatchers both know what kind of trip it is.

Two-way messaging supports text, voice notes, photos, and files. That means a driver can send a quick voice message or a photo of a pickup confirmation rather than typing while driving, and dispatch can send instructions the same way.

Yes. Chat runs on the cloud backend, and media like photos, files, and voice notes is kept in cloud storage rather than crammed into the message database — which keeps chat fast and the media reliable.

Automatically, per trip. You set a commission rate for each driver, and that rate is stamped onto every trip when it happens. The platform totals what's owed for the week without anyone doing the math by hand.

No — and that's deliberate. Because the rate is stamped per trip at the moment of the trip, changing a driver's rate only affects future trips. History never re-prices, so last week's settled numbers stay exactly as they were.

When a driver pays their commission, they upload a screenshot of their Zelle payment. OCR reads the amount off the receipt and, if it matches what's owed within a set tolerance, auto-approves it. Dispatchers only have to manually review the exceptions that don't match — not every single payment.

Settlement runs on a weekly cycle with math that distinguishes cash trips from account/card trips. Cash and card are settled differently, and the platform keeps them straight so the amount a driver owes — or is owed — is correct. Tolls are handled explicitly so they don't distort the numbers.

Yes. The Commission Center shows total owed, paid-and-verified, and pending-review, broken down by driver with their rate and trip count. Verified payments are flagged, and anything that needs a manual look is surfaced for review.

The trip keeps working. Amir Ventures is built with offline hardening: actions and trip completions are written to the phone's disk first in a durable queue, and synced to the backend the moment the connection comes back. A job accepted on a strong signal survives a trip completed in a dead zone.

The system is engineered specifically so they don't. Disk-first queues, a socket watchdog that heals dropped connections, and crash recovery all exist to make sure jobs and completions survive weak service and sync on reconnect. Combined with the audit trail, a dispatcher can trace and restore anything that looks amiss.

The backend is a cloud service, so drivers and other dispatchers keep operating independently of any one device's connection. A dispatcher who reconnects is brought back into sync with the current live state.

It's been running a live fleet in daily production, which is the honest measure of reliability — it holds up through real rush-hour load, weak-signal areas, and edge cases. We don't publish a formal uptime SLA figure; what we can point to is that it's proven in real operations every day, on a serverless backend built for high availability.

Pricing is quote-based and tailored to your operation, so there isn't a public price. The platform is offered as a license, and the right figure depends on factors like fleet size, whether you want a fully separate white-label deployment, and the scope of any customization. Book a demo or request a quote and we'll put together a concrete number.

It's licensed software — the platform is deployed under a licensing agreement, the same model already in place with the live production customer. The exact terms are part of the quote conversation and shaped around what your operation needs.

Because a fair price depends on what you actually need — fleet size, a shared vs. fully separate deployment, brand customization, and support scope all move the number. Rather than post a figure that would be wrong for most operations, we scope it with you and quote honestly.

The full platform — the driver app, the dispatcher command center across phone, tablet, and Mac, and the cloud backend — plus setup, onboarding materials, and support. If you want your own branding and a fully separate backend, that's the white-label option, covered in its own section below.

No. It's a finished, production application your team uses — dispatchers dispatch, drivers drive. You don't need in-house engineers to operate it. Setup, maintenance, and updates are handled as part of the arrangement.

Because it's an already-built, production-proven platform, you're not waiting on development — most of the work is standing up your deployment, configuring your zones and drivers, and training your team. The precise timeline depends on fleet size and whether you're on a shared or fully separate white-label deployment, which we'll scope with you.

Dispatchers are set up in the command center and drivers install the app and sign in with phone and PIN. The app is intentionally simple, and there are printable step-by-step guides for drivers and a manual for dispatchers — all trilingual — so a new person can be productive quickly.

Yes. There's a trilingual driver guide with faithful step-by-step screens and a full dispatcher manual, in English, Russian, and Uzbek. These are available in the document center so you can hand them to your team directly.

Yes — drivers are set up in the system and start receiving jobs immediately. On the client side, the platform builds a client database automatically from the trips you run, so your customer list grows from real activity rather than a manual import. Specifics for your operation are part of the implementation plan.

The apps are built for the Apple App Store and Google Play. For a white-label deployment they're published under your brand. Distribution details are handled as part of standing up your deployment.

Support covers keeping your deployment healthy, fixing issues, and shipping updates. The platform is actively maintained — the live production fleet gets ongoing fixes and improvements — and the same care applies to licensed deployments. The exact support scope and response expectations are set out in your agreement.

The platform has built-in error logging and a black-box audit trail, which makes issues diagnosable quickly — often without needing to reproduce them by hand. Fixes are prioritized by impact: anything that would slow or block real operations is treated as urgent, while smaller improvements are batched into regular update rounds.

Updates are managed to avoid disruption. Many changes are configuration-gated and reversible so they can be turned on carefully, and a blast-radius check is done before shipping. Backend and app updates are rolled out deliberately rather than all at once.

Yes. Many features in the platform today came from real operational needs. Custom development and feature requests can be scoped as part of your engagement — the codebase is one platform, so improvements can flow to your deployment.

The platform is designed to fail safely — offline queues, self-healing connections, and the reassign flow mean a hiccup doesn't strand jobs. And because every event is recorded in the audit trail with one-tap restore, a dispatcher can recover from an odd situation on the spot rather than losing work.

Sign-in is by phone number and PIN, with the option to enable Face ID or Touch ID for fast, secure re-entry. Authentication runs on the cloud backend's identity service, and dispatcher-level access is gated by a dedicated permission.

The backend uses deny-by-default security rules — nothing is readable or writable unless a rule explicitly allows it — and dispatcher privileges are granted through a custom claim, so only authorized dispatcher accounts can perform dispatcher actions.

Your operational data — trips, drivers, clients — is yours. In a white-label deployment each company runs on a separate backend, so your data lives in its own isolated environment rather than being pooled with anyone else's. Ownership and data-handling terms are spelled out in your agreement.

No. The white-label architecture provisions a separate backend per company, so each deployment is fully isolated. That separation is a core part of the design, not an add-on.

It's a durable record of every meaningful event — jobs created, dispatched, accepted, completed, canceled. If something looks wrong, a dispatcher can see the exact history of a job and use one-tap restore to bring it back. It's how the platform stays accountable and recoverable under real-world conditions.

Yes. The auto-built client database supports multi-select and CSV export, so you can pull your client list out for bulk texting or your own records. Trip logs, earnings, and commission data are all visible in the dispatcher app.

Your operational data lives on a managed cloud backend rather than on any single device, and the audit trail provides an event-level record that makes recovery possible. Specific backup and retention arrangements are part of your deployment setup.

The apps are built with Expo and React Native, so a single codebase runs on iOS and Android. The backend is Firebase — Cloud Functions for server logic, Realtime Database for live sync, Auth for identity, and Storage for media. It's a serverless, event-driven architecture.

The driver app runs on iOS and Android phones. The dispatcher command center runs on iOS, Android, iPad, and Mac — the tablet and desktop layouts are responsive, so a dispatcher can work from a big screen or a phone.

It's event-driven. Changes write to the Realtime Database and propagate instantly to every connected app, while Cloud Functions handle server-side logic like dispatch timeouts, notifications, and recurring reservations. That's what makes a dispatched job appear on a driver's phone and every dispatcher's screen at once.

The serverless backend is built to scale with usage rather than on fixed servers you manage. It's proven with a 30+ driver fleet in daily production, and the architecture is designed to grow with your operation.

Three: English, Russian, and Uzbek. Each user picks their own language for the app display and alerts, so a mixed-language fleet all work in the language they're comfortable with.

The platform is a complete, self-contained system today rather than an integration marketplace. Because it's built on a flexible cloud backend and a single codebase, specific integrations or data exchanges can be scoped as custom development for your deployment. Bring your requirements to the demo and we'll tell you honestly what's feasible.

Job pushes are sent as Time-Sensitive notifications at a higher delivery priority, which lets them break through Do-Not-Disturb and Focus modes — including the Driving Focus that a car connection often turns on. Push tokens are managed so a driver on multiple devices is reached correctly.

Yes. That's the white-label architecture: one codebase with per-company brand packs, so your apps carry your name, colors, and identity while running on the same proven platform. Each company also gets its own separate backend.

There's a single shared codebase, and each company is a brand pack layered on top with its own look and its own dedicated backend. This means improvements to the core platform can benefit every deployment, while your branding and data stay entirely your own.

Fully. Each company runs on a separate backend, so your data, drivers, and configuration are isolated in their own environment. There is no shared database between white-label deployments.

Yes. Brand packs cover your name, colors, and visual theme — the platform already ships distinct themes for different brands. The scope of theming for your deployment is part of the white-label conversation.

A white-label deployment is published under your brand on the app stores. Store listings and distribution are handled as part of standing up your deployment, so your drivers and dispatchers download your app.

Yes. Because it's one codebase with per-company deployments, custom development can be scoped for your build. Bring your requirements and we'll tell you honestly what fits the platform and what would be a larger undertaking.