How to Build an App Like Uber or Zomato — Architecture & Real Costs

Building an on-demand marketplace MVP like Uber or Zomato costs ₹8,50,000-₹14,00,000 ($10,000-$17,000) with a freelance developer in India, taking 10-14 weeks. This includes a customer app, provider app, admin panel, payment integration, and live location tracking. Monthly running costs start at just ₹2,000-₹4,000 ($25-$50) for your first 1,000 users. Agencies quote ₹20-40 lakhs for the same scope because they sell the fantasy of replicating Uber's full platform.

"I want to build an app like Uber" is the most common request freelance developers get. And it's the most misunderstood.

Uber has 5,000+ engineers. Their tech stack includes custom-built infrastructure that cost billions to develop. When you say "build an app like Uber," what you actually mean is: "build an on-demand marketplace MVP that connects providers with customers."

That's a very different thing. And it's very buildable.

Agencies will quote you $200K-500K for "an app like Uber." That's because they're selling you the fantasy of replicating Uber's entire platform. What you actually need for an MVP is 10% of that — and it can be built for $8K-15K.

Let me break down what you actually need.

Every on-demand app has the same core components:

1. Three user types: - Customer (orders/books) - Provider (driver/restaurant/service provider) - Admin (manages the platform)

2. Core features per user type:

Tech stack I'd use: - Mobile: React Native (Expo) — one codebase for iOS + Android - Backend: Spring Boot or Node.js with Express - Database: PostgreSQL via Supabase - Maps: Google Maps API (₹14,000 free credit/month) - Payments: Razorpay (India) or Stripe (global) - Push notifications: Firebase Cloud Messaging (free) - Real-time: Supabase Realtime or Socket.io

What you DON'T need for MVP: - Microservices architecture (monolith is fine for <10K users) - Machine learning for matching/pricing (simple algorithms work) - Custom map rendering (Google Maps API handles everything) - Multi-region deployment (single region is fine until you scale)

Here's what it actually costs to build an on-demand MVP with a freelance developer in India:

Development costs: | Component | Time | Cost | |-----------|------|------| | Customer mobile app | 3-4 weeks | ₹2,50,000-4,00,000 | | Provider mobile app | 2-3 weeks | ₹1,50,000-2,50,000 | | Backend API + database | 3-4 weeks | ₹2,50,000-4,00,000 | | Admin dashboard (web) | 1-2 weeks | ₹1,00,000-1,50,000 | | Payments integration | 1 week | ₹50,000-1,00,000 | | Maps + location tracking | 1 week | ₹50,000-1,00,000 | | Total | 10-14 weeks | ₹8,50,000-14,00,000 ($10K-17K) |

Monthly running costs (first 1,000 users): | Service | Monthly Cost | |---------|-------------| | Hosting (Amplify/Vercel) | ₹0-2,000 | | Database (Supabase Pro) | ₹2,000 | | Google Maps API | ₹0 (free tier covers it) | | Firebase (notifications) | ₹0 (free tier) | | Razorpay | 2% per transaction (no fixed cost) | | Total | ₹2,000-4,000/month (~$25-50) |

Compare this to agency quotes of ₹20-40 lakhs and monthly infrastructure costs of ₹50K+. The difference is scope discipline — building what you need, not what sounds impressive.

Common cost traps with on-demand apps: The biggest hidden cost is the payment split feature. In a marketplace, you collect payment from the customer and split it between the platform and the provider. This requires a proper escrow or marketplace payment flow (Razorpay Route or Stripe Connect), which is significantly more complex than simple one-way payments. Budget an extra ₹1,00,000-₹2,00,000 and one additional week specifically for marketplace payments. Another trap is push notifications at scale — Firebase is free, but delivering time-sensitive notifications reliably to thousands of providers requires proper handling of device tokens, retry logic, and silent notifications for background location updates.

Real-time location tracking is the feature that makes on-demand apps expensive. Here's how to handle it without overengineering:

MVP approach (works for <5K concurrent users): 1. Provider app sends location updates every 10 seconds via WebSocket 2. Server stores the latest position in PostgreSQL (or Redis for lower latency) 3. Customer app polls or subscribes via Supabase Realtime

Why 10-second updates are fine: Uber updates every 4 seconds. You don't need that. For food delivery, a pizza doesn't move that fast. For ride-sharing with 50 drivers, 10-second updates are smooth enough.

What Uber does differently: They use a custom-built system called Ringpop for distributed location processing across regions. You don't need this. You need a WebSocket that sends coordinates every 10 seconds. Don't let anyone tell you otherwise.

Google Maps API costs: Google gives you $200 free credit/month (~₹14,000). That's roughly: - 28,000 map loads - 40,000 geocoding requests - 10,000 directions requests

For an MVP, this free tier is more than enough. You start paying only when you have thousands of daily active users — which is a good problem to have.

The biggest mistake with on-demand apps is building the full platform before proving demand. Here's a better approach:

Phase 1 — Validate (2-4 weeks, ₹0-50K): - Build a WhatsApp-based order system. Customer orders via WhatsApp, you manually match with providers. - If you can't get 50 orders in a month with a manual process, an app won't save you.

Phase 2 — MVP (10-14 weeks, ₹8-14L): - Build the customer app, provider app, and admin panel - Launch in ONE city, ONE category - Target 100 daily orders

Phase 3 — Scale (ongoing): - Add features based on user feedback - Expand to new cities only after dominance in the first one - Now consider: caching, CDN, read replicas, maybe microservices

I've seen founders skip Phase 1 and go straight to building a full-featured app. Six months and ₹15 lakhs later, they have 12 users. Don't be that founder.

The apps that win aren't the ones with the best technology — they're the ones that solve a real problem in a specific market. Build the smallest thing that connects supply and demand. If it works on WhatsApp, it'll work as an app.

Lesson from failed on-demand startups: The graveyard of on-demand apps is full of platforms that launched in 10 cities simultaneously. They burned through cash on marketing and provider acquisition in markets they did not understand. Compare this with successful regional platforms that dominated one city first — learning the supply dynamics, pricing expectations, and customer behavior in a single market before expanding. Your MVP should target one city, one service category, and 100 daily orders. If you cannot achieve that level of product-market fit in a single geography, expanding to more cities will only multiply your losses. Depth beats breadth at the MVP stage.

Q: Can I build an Uber clone for $5,000?

No. Anyone quoting $5,000 for a full on-demand app with customer app, provider app, admin panel, payments, and live tracking is either using a low-quality template with no customization or will deliver an incomplete product. A realistic MVP costs ₹8,50,000-₹14,00,000 ($10,000-$17,000) for 10-14 weeks of development by a senior freelancer. You can reduce cost by starting with a simpler scope — for example, building only the customer app first and managing providers through a basic admin dashboard instead of a separate provider app.

Q: Should I build separate apps for Android and iOS or use cross-platform?

Use a cross-platform framework like React Native with Expo. You get one codebase that runs on both platforms with 95% code sharing, cutting development cost nearly in half. The performance difference is negligible for on-demand apps — React Native handles maps, location tracking, push notifications, and real-time updates perfectly. Building separate native apps in Kotlin and Swift only makes sense if you have very specific platform requirements like AR features or complex animations, which on-demand apps typically do not need.

Q: How do I handle payments in a marketplace app in India?

Use Razorpay Route for marketplace payment splitting. The flow works like this: customer pays the full amount, Razorpay holds the funds, then splits the payment between your platform commission and the provider payout based on your configured rules. This handles TDS compliance, automated provider settlements, and refund processing. The integration takes about one week and costs ₹50,000-₹1,00,000 in development. Avoid building custom payment splitting logic — the regulatory and compliance requirements around holding and disbursing funds in India make this a problem you want a payment gateway to solve for you.

Q: How many users can an MVP on-demand app handle before needing to scale?

A well-built MVP on a monolithic architecture with PostgreSQL and Supabase Realtime can handle 5,000-10,000 registered users and 500-1,000 concurrent users comfortably. At ₹2,000-₹4,000 per month in infrastructure costs, this capacity is sufficient for validating product-market fit in a single city. You only need to think about scaling when you consistently see database query times above 200ms or WebSocket connection drops during peak hours. At that point, adding Redis for caching and read replicas for the database extends your capacity to 50,000+ users.

Q: Do I need machine learning for matching customers with providers?

Not for your MVP. Simple algorithms work perfectly for early-stage on-demand apps. For ride-sharing, match the nearest available driver. For food delivery, assign orders to the nearest available delivery partner. For service marketplaces, show providers sorted by distance and rating. Uber and Zomato use ML for matching because they optimize across millions of simultaneous requests — your MVP will have dozens. Add ML-based matching only when your simple algorithm demonstrably fails to optimize utilization or customer wait times at scale.