White-Label Taxi App: What to Check Before Buying the Source Code

"Source code included" can mean five different things, and buyers often discover which one only after the money has moved. This article is an acceptance test you can run before you pay: license rights, a clean-machine build, whose name is on the store and API accounts, a live trip with you watching, a sample data export, and a clear answer on who maintains the code when a map or payment provider changes its API.

Ptaxi sells a source-code platform for taxi and ride-hailing operators. Treat the checklist below as something you can send to us, or to anyone else on your shortlist, and ask for written answers.

Three things get sold as "white-label"

The phrase covers products that look similar in a demo and behave differently once you own them.

A hosted rebrand puts your logo and colors on a vendor-run service. You rent access. You usually cannot move the system to your own servers, and you cannot change how dispatch or pricing works beyond the switches the vendor exposes. That is fine for fleets that want bookings and nothing else.

A packaged script is a downloadable product with limited customization. You may get some of the code, or none of it. Changes often wait on the vendor's release schedule. Quality varies widely; the only reliable test is whether a developer who is not the seller can build and run it.

A platform with source code delivers the working apps and backend so you can host them and change them. You still need someone technical, and you inherit the architecture the vendor chose. That middle route is what we sell, which is why we have an interest in how this checklist is written. Hold us to it the same way you hold anyone else. For a broader comparison of clone scripts versus custom builds, see Uber clone vs custom build.

White-label is branding. Source code is what arrives in the delivery. Ownership is what the license actually grants. Keep those three words separate when you talk to sales.

Read the license for three rights

Before you argue about features, open the license and look for three permissions in plain language.

Can you modify the code (dispatch rules, pricing, payments, UI) without asking for a new release? Can you host it on servers you choose, including switching providers later? Can you use it for more than one brand or city under the same purchase, or does each market need another fee?

A license that lets you modify but not host elsewhere, or host but not modify, is a rental with extra steps. Ask what the license forbids as well: resale, redistribution, or using the code to build a competing product for other operators are common limits. None of that is unusual; what matters is that you know the limits before you sign.

If a vendor will not put those three rights in writing, treat "source code" as a marketing phrase until they do.

Build it yourself on day one

Clean-machine build of both apps and the backend

Ask for a repository (or archive) that a developer who has never touched the project can build on a clean machine: passenger app, driver app, admin console and backend. If the only person who can produce a working build is the seller's engineer with a private setup, you do not yet have a deliverable you can maintain.

You do not need to finish the build yourself if you are not technical. Hire someone independent for a day. Their job is to follow the vendor's instructions, note every missing step, and report whether the apps install and talk to the backend. That day of work is cheaper than discovering the gap after launch.

What "full source code" should include, as a buyer's checklist rather than a claim about any one product: both mobile apps, the backend, the admin console, build and signing instructions, and API documentation for the integrations you will touch. If any one of those is missing, replacing the vendor later gets hard. Exact packaging varies by seller — ask for a written inventory of what ships, and do not accept a slide as a substitute.

Whose accounts?

App-store developer accounts, push-notification credentials, map API keys, SMS providers and payment merchant accounts should be created under your legal entity from day one. If the vendor holds them, they can still lock you in after handing over the code: a revoked key stops the apps as effectively as withheld source.

Ask who creates each account, whose billing account is on file, and how credentials are transferred if you part ways. Put the answers in the contract schedule.

Make them run a trip while you watch

A polished homepage does not prove dispatch works. Sit through one full trip on the vendor's demo: passenger requests a ride, a driver receives it, an operator reassigns the order in the admin console, the trip ends, and payment settles.

Watch it on a mid-range Android phone and on a throttled mobile connection, not only on the vendor's office Wi-Fi. Ask to see the settings that matter operationally: search radius or acceptance range, offer timeout, and manual reassignment for reserved trips. Those are the levers you will live with. Our note on how taxi dispatch software assigns orders explains why those settings decide pickup times; you are checking that the product you are buying actually exposes them.

If the demo cannot reassign a reserved trip from the admin console, write that down. Airport and pre-booked work will hurt without it.

Data and exit

Ask for a sample export of riders, drivers, trips, fare components and service zones, in a format your team can open without the vendor's software. Prefer something boring and portable (CSV or SQL dump) over a proprietary archive.

Then ask the exit question out loud: if you stop paying for hosting or maintenance, how long does your data stay available, and in what form do you get it? On a system you host yourself, the data is already in your database — confirm backups are yours to run. On a vendor-hosted plan, the answer must be in writing, with a time limit you can live with.

Who maintains it when a provider changes its API

Map providers, payment processors, push services and the app stores change requirements every year or so. A stale integration breaks on a weekday afternoon with no warning.

Ask what the maintenance plan covers: dependency updates, store guideline changes, security patches, and which of those are included versus billed as projects. Do not accept "we support you" without a scope. Ask for current prices from each third-party supplier yourself (maps, SMS, push, hosting); they change, and a blog post cannot quote them honestly for every market.

If you have no technical person and do not plan to hire one, source code is the wrong product. A hosted plan that someone else keeps alive will cost less in missed trips than a repo you cannot update.

When a hosted plan is the better buy

Buy hosted white-label when you need a booking app for an existing fleet, you do not expect to change dispatch or pricing logic, and you would rather pay a monthly fee than keep a developer on call. Small fleets that only want passengers to request cars and pay often fit here.

Buy source code when you expect to change rules as you learn, when you want the option to replace the vendor, or when hosting and data residency matter enough to run the stack yourself. That is a product decision, not a moral one.

A one-page acceptance list

Send this list as-is. Ask for written answers before any deposit.

• License grants modify, host-anywhere, and multi-brand/city use (or states the limits clearly).
• Delivery inventory lists passenger app, driver app, admin console, backend, build/signing docs and API docs.
• A developer who is not the seller can build both apps and the backend on a clean machine from the delivered materials.
• App-store accounts, push credentials, map keys, SMS and payment merchant accounts are created in the buyer's name.
• Live demo: request → driver accept → operator reassign → trip end → payment, on a mid-range phone and a slow network.
• Admin exposes dispatch range/timeouts and manual reassignment for reserved trips.
• Sample export of riders, drivers, trips, fare components and zones in a portable format.
• Written exit terms for data after you stop paying (hosted) or confirmation that backups are yours (self-hosted).
• Maintenance scope: what is included when map, payment, push or store rules change, and what is billed separately.
• Honest statement of what the vendor will not do (for example, local operating licenses and insurance remain yours).

Compliance in your city — platform permits, vehicle and driver rules, insurance — is your problem to solve with local advisors. Software vendors are not law firms, and neither are we.

If you want answers against this list for your market and fleet size, ask for the demo apps and send the checklist with the quote request. We will answer each line in writing. You can also review the ride-hailing platform and the feature list before the call so the conversation stays on what the product actually does.