What custom software actually costs in India, and what moves the number

Ask five software studios what a project costs and you will get five numbers that do not overlap. One quotes two lakh, one quotes forty. Both are describing the same brief. That spread is not dishonesty, it is the absence of a shared unit, and it leaves buyers with no way to tell a fair price from a bad one.

So here is how the pricing works underneath, written plainly, from a studio that quotes fixed price and therefore has to be right about this.

The only thing that actually drives cost is screens and rules

Software cost is not driven by the technology. It is driven by two things: how many distinct screens a person has to be able to use, and how many rules sit behind them. A screen that lists records is cheap. A screen that lists records, filters them six ways, lets three roles edit different fields, locks after approval, and emails somebody when a date passes, is not one screen. It is a week.

When you read a quote, count the screens the proposal names. If it names four and you can think of nine, the quote is not for your project.

The honest bands

These are the ranges we see in the Indian market for work that is built properly, handed over, and does not need the builder in order to keep running.

• A single internal tool, one or two roles, six to ten screens: roughly 1.5 to 4 lakh. An approvals tracker, an inspection app, a stock register.
• A full web application with several roles, a dashboard and an integration: roughly 4 to 12 lakh. This is the bulk of what mid sized businesses need.
• A platform with external users, payments, and compliance requirements: 12 lakh and up, and the number depends almost entirely on the compliance part.
• An ERP or CRM integration on its own: 1 to 5 lakh, depending entirely on whether the system on the far end has a real API.

Anything materially below those bands is being delivered by someone who intends to make the money back on changes, maintenance or by handing you a codebase nobody can take over. That is not a cheaper project. It is a deferred invoice.

What makes the number go up, in order

If you want to control the price, these are the levers, strongest first.

• Number of user roles. Each role is a different set of permissions, a different screen layout and a different test case. Going from one role to three can add half the project.
• Approval chains. A field that one person edits is trivial. A field that routes through two approvers, can be rejected, reopened and must keep a history, is a module.
• Integrations with systems you do not control. The cost is not the code, it is the waiting. If the vendor's API is undocumented, or access needs their consultant, the schedule belongs to them.
• Offline use. Working without signal means queuing, syncing and conflict resolution. It is worth it when crews work on sites, and it is money wasted when everyone sits in an office.
• Reporting that must be exactly right. Dashboards are cheap. Dashboards that must reconcile to the rupee with your accounting system are not.
• Migration of old data. Clean data is a day. Fifteen years of inconsistent spreadsheets is a fortnight, and it is nobody's favourite work.

What does not move the number as much as people think

Design quality barely changes the cost, because the work is in the thinking rather than the pixels. Nor does the choice of framework. And nor, mostly, does the number of records: a system holding ten thousand rows and one holding ten million are the same build until you get to serious scale.

The thing buyers most often pay extra for without benefit is a feature list assembled by asking everyone what they want. Half of it is never used. A good studio will cut that list in the scoping call, and the cut is worth more to you than the discount you were going to negotiate.

Fixed price or hourly

Hourly billing moves every risk onto you. If the estimate was wrong, you pay for it. If the developer is slow, you pay for it. If the scope was vague, you pay for the conversation. The incentive points the wrong way, and everyone involved knows it.

Fixed price moves that risk to the studio, which is where it belongs, because they are the ones who can estimate. The honest version has a written scope, a named date and a clear statement of what is not included. The dishonest version has a low headline and a change request for every sentence you did not think to write down.

The question that separates them: ask what happens if the build takes twice as long as they thought. If the answer costs you money, it is not fixed price.

The questions that save you the most money

Before you compare quotes, ask every studio the same six things. The answers will tell you more than the numbers.

• What is explicitly not included in this price?
• Who owns the code and where does the repository live?
• What happens if we want a change halfway through?
• What does support cost after launch, and what does it cover?
• Can we see something working before the final week?
• If we wanted to move to another developer in a year, what would that take?

The last question is the one that reveals most. A studio that has built for handover answers it in a sentence. A studio that has built for lock in starts explaining why you would never want to.

A rule of thumb that holds up

Work out what the current process costs you in time. Hours a week, multiplied by what those hours are worth, multiplied by fifty. If the software costs less than one year of that, it is almost always worth building. If it costs more than two years of it, the scope is too big and should be cut rather than financed.

That calculation has killed more of our own proposals than any competitor has. We would rather lose a project than build something that does not pay for itself, because the ones that do not pay are also the ones that get abandoned, and an abandoned system is worse than the spreadsheet it replaced.