Ask three development agencies what a taxi app costs and you will get three numbers, all of them for the same thing: a first version that demonstrates well.
None of them is wrong. They are answering a different question from the one you are asking, which is what will this cost me to have running in two years.
What the quote covers
A typical quote covers the visible product: a passenger app, a driver app, an admin panel, a map integration, a payment gateway, and enough of a back end to make them talk. Delivered, demonstrated, invoiced.
That is real work and it is worth what it costs. The gap is everything that starts the day after.
The seven things quotes leave out
1. Two app stores, forever. Apple and Google change their requirements every year. Apps that are not updated get pulled. That is not a one-time cost; it is a subscription you pay in developer time whether or not you wanted a new feature.
2. Android fragmentation. Your drivers are not on flagship phones. They are on four-year-old devices with aggressive battery management that kills background location. Making tracking survive that is not a feature — it is weeks of work you cannot discover until you are live.
3. GST that reconciles. Place of supply, reverse charge, SAC codes, financial-year numbering, one invoice per treatment. Every one of these is easy to get slightly wrong and expensive when a client’s finance team rejects the invoice.
4. The tariff engine. City fares, hourly packages, outstation slabs, extra km, extra hours, waiting, tolls, night charges, driver allowance, negotiated corporate rates. This is where custom builds run over, every time, because nobody scopes it properly at quoting stage.
5. Someone on call. Dispatch fails at 6am. Who answers? A retainer with the agency covers office hours in their timezone, not yours.
6. The developer leaving. The person who built it holds the knowledge. When they move on, the next developer’s first estimate is to rewrite the parts they cannot understand.
7. Hosting, monitoring and the map bill. Small individually. Permanent.
How to compare the two numbers honestly
Build a two-year figure for both options. Not one year — the first year always flatters a build, because the maintenance has not started.
| Line | Build | Licence |
|---|---|---|
| Initial | Development quote | Implementation and configuration |
| Monthly | Hosting, monitoring, retainer | Subscription |
| Ongoing dev | Store compliance, fixes, changes | Included |
| Tax logic | Your problem | Already built |
| Time to live | Months | Weeks |
| Key-person risk | High | Contractual |
| Owns the code | You | You licence it |
Then ask the question that actually decides it: what is the cost of being six months late? If a corporate contract is waiting on this, six months of lost revenue frequently exceeds the entire difference between the two columns.
When building is genuinely right
We would rather say this than pretend otherwise:
- Your operation is unusual enough that no product models it, and you have tested that belief rather than assumed it.
- You already run a software team with product management and a release process, so the marginal cost is much lower than it would be for someone hiring from scratch.
- The software is the business — you are building a platform to sell, not a fleet to run.
If none of those is true, you are proposing to spend your scarcest resource on something that will never be a competitive advantage. Nobody has ever chosen a taxi company because its dispatch software was bespoke.
The middle path most people miss
Licence now, build later if you must. Running a configured system for a year teaches you what your rules actually are — which is precisely the expensive thing to discover halfway through a build, when changing the model means rewriting what already exists.
Our comparison with building in-house sets the two options side by side including where building wins, and pricing is published in full so you can put a real number in the right-hand column rather than asking for one.