Ask five agencies what an app costs and you will get five numbers that are nowhere near each other. That is not always dishonesty. "An app" can mean a five-screen catalogue or a live logistics platform, and the same words describe both.
So rather than quote a number, here is what actually drives the cost, what we see projects land at, and the running costs that most quotes quietly leave out.
What actually drives the price
1. The number of user types
This is the single biggest multiplier and it is almost never in the brief. An app with one kind of user is one app. A marketplace with buyers and sellers is two. A delivery platform with customers, riders and an operations team is three products plus a dashboard, even though everyone still calls it "an app".
When we scoped our own ride-hailing platform, the passenger experience was the smallest part of the work. Driver onboarding, document verification, live dispatch and the operations console were the bulk of it.
2. Whether anything happens in real time
A screen that loads a list is cheap. A screen that updates as something moves is not. Live tracking, live chat, live availability and anything involving two devices agreeing on state all add infrastructure, edge cases and testing that a static app never needs.
3. Payments
Taking money is never a small feature. Payment gateway integration, refunds, failed transactions, reconciliation and the reporting your accountant needs each carry work. In Pakistan you usually need more than one method, because customers who will not use a card will happily use a bank transfer or cash on delivery, and each route needs its own confirmation flow.
4. Whether it works offline
If your users are couriers, field staff, or anyone in a basement or a rural area, the app has to keep working with no signal and reconcile when it returns. Offline-first is a design decision, not a feature you add later, and retrofitting it is usually more expensive than the original build.
5. Who maintains it after launch
An app is not a building. Android and iOS both ship breaking changes every year, and the stores enforce them. A build that nobody touches for eighteen months is usually a build that has stopped installing on new phones.
Indicative bands
These are the ranges we see for well-scoped work delivered to production quality, both platforms from one codebase. They are a starting point for a conversation, not a price list, and any serious quote should come after a scoping call rather than before it.
| Type of app | What it involves | Indicative range (PKR) | | --- | --- | --- | | Simple catalogue or booking app | One user type, content from a backend, contact and enquiry flows | 400,000 - 900,000 | | Business app with accounts | Login, profiles, saved data, notifications, an admin panel | 900,000 - 2,000,000 | | Marketplace or two-sided app | Two user types, payments, ratings, moderation, dashboard | 2,000,000 - 5,000,000 | | Real-time platform | Live tracking, dispatch, multiple roles, operations console | 5,000,000 upwards |
The single most useful thing you can do to control which band you land in is to cut the first version hard. Almost every feature that feels essential in month one turns out to be unnecessary once real users arrive, and you will discover which ones by launching, not by planning.
The costs nobody puts in the quote
- Store accounts. Google Play is a one-time fee, Apple charges annually. Both should be registered in your name, not your developer's.
- Backend and hosting. Small at first, but it scales with users. Ask what it costs at ten times your launch volume, not at launch.
- Maps and messaging. Map tiles, routing, SMS and push all bill per use. On a mapping-heavy app this can quietly become your largest running cost, which is exactly why we build on open routing rather than a per-request commercial API where we can.
- Maintenance. Budget for it annually. It is the difference between an app that lasts and one you rebuild in two years.
- Marketing. An app with no users is an expensive private project. Whatever you spend building it, plan for getting it in front of people.
Fixed price or hourly?
Fixed price per phase, in our view, as long as the phase is genuinely defined. It puts the risk of estimating badly on us, where it belongs, and it gives you a number you can plan around.
What fixed price does not survive is a scope that keeps moving. That is why we split projects into phases with a written scope for each: you get price certainty on what is agreed, and changes get priced honestly instead of being absorbed silently or fought over later.
The question worth asking first
Before "how much does it cost", ask "what is the smallest version that would prove this works". Almost every expensive app failure we have seen came from building the full vision before anyone had checked whether the first slice mattered to anybody.
If you are weighing up an app, send us a description of what you are trying to do. You will get a straight answer about the scope, the band it falls into, and whether an app is even the right shape for it.