'How much for an app like Zomato?' is a question we get in some form most weeks. It is a reasonable question asked in an unreasonable unit. Zomato is a decade of engineering, hundreds of people and several distinct businesses. The version of it you can build first is a much smaller thing, and knowing which smaller thing is most of the work.
Rather than quote a number that means nothing without context, here is what actually drives the cost — so you can estimate your own project, and so you can tell whether a quote you have received is serious.
What barely matters: screen count
Estimating by number of screens is the most common approach and the least accurate. A settings screen is a day. A checkout screen touching payments, inventory, tax and fraud is a fortnight. Both are one line on a wireframe.
The same applies to the design. A visually rich interface costs marginally more than a plain one. The gap between an ugly product and a beautiful one is far smaller than the gap between a product with two integrations and one with eight.
What actually matters
1. Integrations
Every external system is a unit of work with a long tail: sandbox access, credentials, an API that behaves differently from its documentation, error cases nobody wrote down, webhook verification, retry semantics, and a support ticket that takes eleven days. Payment gateways, SMS providers, logistics partners, ERPs, government APIs, mapping services — count them honestly. Each one is meaningfully more work than it appears in a kickoff meeting.
2. Number of user types
A marketplace with buyers, sellers and admins is roughly three products sharing a database. Each role needs its own flows, permissions, notifications and edge cases. Going from one user type to two rarely doubles the cost, but it is closer to doubling than to adding ten percent — and it is the most common reason a scope estimate is wrong by a factor.
3. Compliance and regulation
Health, finance and education carry requirements that shape the architecture rather than sitting on top of it: consent management, audit trails, data residency, retention policies, KYC. These cannot be added at the end. If you are in a regulated space, that fact belongs in the first estimate conversation, not the third.
4. Platforms
Web only is one build. Web plus mobile is two, unless the web part is thin. Android plus iOS from a shared Flutter codebase is close to one and a bit. And an admin panel is not free — it is a real application that your operations team will use more hours per day than your customers use the customer app.
5. Real-time and offline requirements
Live tracking, chat, collaborative editing and offline-first sync each add architectural weight well beyond their apparent size. 'Users should see updates instantly' and 'it should work without a network' are two of the most expensive sentences in a product brief, and both are frequently negotiable once someone explains the cost.
6. Scale on day one
Building for ten thousand users is straightforward. Building for ten million from launch is a different system, and if you do not have ten million users yet, building it now is a way of spending your runway on a problem you may never have. Build for the next order of magnitude, not the final one.
Where the money actually goes
A rough shape of a well-run project, useful for sanity-checking a quote:
- Discovery and specification: around a tenth of the effort, and the highest-leverage tenth there is.
- Design: roughly a sixth, more if the product is design-led.
- Engineering: about half, split across backend, frontend and mobile.
- Testing and release engineering: around a sixth, and the first thing cut in a bad plan.
- Project management and communication: the remainder, and it is not overhead — it is what stops the other four from drifting.
How to make it cheaper — legitimately
- 01Cut user types before you cut features. Launch for one side of the marketplace and operate the other manually until volume justifies software.
- 02Do things manually that look automatable. Ops-heavy first versions are how many good products started, and they teach you what to automate.
- 03Ship one platform. Android-first is the right call for most Indian consumer products, and it halves your surface area while you learn.
- 04Use boring, managed infrastructure. Your differentiation is not your deployment pipeline.
- 05Defer the admin panel by giving your team read-only database access and a few scripts — for the first few months only.
- 06Buy rather than build for anything that is not your product: auth, payments, notifications, analytics, support.
How it gets expensive — illegitimately
- No specification, so scope is renegotiated weekly and every conversation restarts from first principles.
- A rewrite proposed instead of a diagnosis, because rewriting is easier to sell than reading someone else's code.
- Junior engineers billed at senior rates after a senior architect fronted the pitch.
- Infrastructure sized for a scale that has not arrived and may not.
- Custom-built components — auth, admin frameworks, notification systems — that a mature library would have provided in a day.
The most useful thing you can do before commissioning software is spend a small amount of money on a discovery sprint with whoever might build it. You will get a specification you own regardless of who you hire, an estimate grounded in something, and a fairly clear read on whether these are people you want to work with for the next six months.