What drives the cost of a web app in India

Two businesses ask for “an inventory app”. The first needs one screen where a shop manager adds and removes stock. The second needs three warehouses, purchase orders, GST invoices, barcode scanning on phones, a Tally sync, and branch managers who see only their branch.

Both requests use the same words. The second is far more work than the first. That’s why price lists online tell you little about your project. What helps is knowing which factors make the work bigger, so you can compare quotes and decide where to spend.

One kind of user is simple. Owners, managers, staff, accountants and customers who each see different data and can do different things means more screens, more rules and more testing. Write down rules like “branch managers see only their branch” and “sales staff can’t see margins” early.

Each connection to another system has to be built, tested, and made to cope when the other side fails. Common ones in India include Razorpay (with refunds and failed payments), WhatsApp through the WhatsApp Business Platform, SMS (which needs DLT registration of sender IDs and templates), Tally or Zoho Books, GST e-invoicing if your business must generate an IRN, and your CRM, ERP or courier partner.

Tally usually takes more custom work than tools with a modern web API. Two-way sync takes much more work than one-way. Our integrations page explains how we approach these connections.

Years of customers, products and transactions in Excel or an old system rarely import cleanly. Duplicate customers, phone numbers in five formats and missing GSTINs all need cleaning. Decide what to bring across, how far back, and who does the cleaning.

Screens built from a proven component library cost less than a fully custom visual design with bespoke illustrations and animation. For internal tools, clarity matters more than originality. For a product customers pay for, design may deserve a bigger share.

A responsive web app serves phones and desktops from one codebase. Separate Android and iOS apps add work. Each extra language adds translation and testing work.

Discount rules, commission slabs, approval chains and credit limits are where hidden complexity lives. “A simple report” might be one table, or a filterable dashboard with exports. List each report and who reads it.

An internal tool for ten staff is different from a customer app that takes payments and stores personal data. Audit logs, two-factor login, detailed access control and handling busy periods all add work, and some of it shouldn’t be skipped.

Generating GST invoices and other PDFs, accepting uploads such as photos and ID documents, and sending emails, SMS or WhatsApp messages at the right moments each add screens, templates and testing. List every document the app must produce and every message it must send.

A live dashboard that updates as orders arrive, or a field app that keeps working without signal and syncs later, takes more engineering than pages that load when someone opens them. Ask whether “live” really needs to be live, or whether a refresh every few minutes will do.

Reading bills, classifying enquiries or answering questions from your documents means testing on your real data, deciding what happens when the AI is unsure, and usually building a review step for staff. Those parts often take longer than connecting the model itself.

Unclear requirements get paid for twice: once when the team guesses, and again when the guess is corrected.

Each factor comes down to one question about your app.

The build price isn’t the full cost of owning the app. Hosting and databases grow with usage. Meta charges for most WhatsApp template messages, and SMS is billed per message. AI features are billed by usage. Domains and business email renew every year, and some tools bill in US dollars. Ask for each of these in writing, even when the amount depends on how much you use.

• Who uses the app, and what each type of user does.
• The three or four core flows, step by step.
• The tools it must connect to, and what moves between them.
• Existing data to bring in.
• The reports you need.
• What already exists: designs, a brand guide, an old system.
• Your budget range. It tells the team whether to propose a fuller build or a focused first version.

Then ask for a written scope before you accept a price. Our guide to scopes of work shows what one should contain.

Start with a focused first version. Use a component library for internal screens. Keep rare tasks manual for now. Replace two-way sync with one-way where the business allows it. Migrate only the data people actually use.

We quote a fixed price against a written scope of work, and anything you add later is quoted before we do it. Our contact form asks for a budget range in rupees, so our first reply fits what you plan to spend.

If you are not sure you need a web app at all, a website is usually less work: it mostly presents information, while a web app stores data and runs business rules. For company or booking sites, see our websites page.