Search for what a custom ERP costs in India and you will find ranges: four lakh to forty-five, twenty to sixty for a mid-sized business, upward of a crore for an enterprise system. Every one of those numbers is published by a firm that cannot stand behind it, because none of them has seen your process, your integrations or your data.
We do not publish a range, and the reason is not coyness. A number quoted before the variables are known anchors the entire conversation to a figure that will move — and the direction it moves is rarely down. What follows is the alternative: the five things that actually decide the number, and how to measure yours before anyone quotes.
1. Process variance — the variable that dominates
How far the way you work differs from the way a template assumes you work. This single variable moves the estimate more than the other four combined, and it is the one buyers most often assume is small.
It is worth being precise about what counts. A different approval threshold is configuration. A different shape of approval — three parties signing in an order that changes by customer category — is engineering. A standard order-to-cash flow is cheap; a flow where price depends on a grade assay arriving after despatch is not.
The useful question is not "are we unusual" — everyone believes they are. It is which specific steps have no equivalent in a packaged product, and whether those steps are a differentiator or an accident of history. Building around an accident encodes it for another decade.
2. Integration surface
Every system the platform must exchange data with is a contract to build, test and maintain. This is the line most consistently underestimated, because integrations are invisible in a requirements document — they appear as a single bullet reading "integrates with existing systems".
What changes the effort is not the count but the character:
- Does an interface actually exist? A brochure listing an API is not the same as an API that exposes the field you need, at the volume you need, without a nightly maintenance window.
- Is it two-way? Reading is straightforward. Writing back into a system of record carries reconciliation, idempotency and failure handling that reading does not.
- Who owns the other end? An integration with a vendor who will not take your call is a different project from one with an internal team.
Count them honestly, and mark which ones are two-way. Five read-only feeds is a smaller job than two bidirectional ones.
3. The condition of the data
Migration effort tracks data quality, not record count. A million clean transaction rows move in an afternoon; four thousand item masters that disagree with each other can hold a go-live for a quarter.
The failures are consistent: the same material under several codes across plants, units of measure that do not reconcile, vendor records missing tax registration, opening stock that has never matched the physical count. None of it is a discipline failure — it is what happens when a system is used for a decade by people whose job is to keep material moving.
This is the cheapest variable to measure and the most commonly measured too late.
4. Module count in the first phase
A phased build prices per phase. Six modules in phase one is not six times one module — there is shared foundation work — but it is not close to the same either, and it moves the date of first value a long way out.
The sequencing that keeps cost proportional to benefit: start with whichever process is currently being run on a spreadsheet beside the existing system. That spreadsheet is a measured signal of where the template stopped fitting, and replacing it produces value the business can feel in the first phase rather than the third.
5. How much of the work happens on site
Discovery conducted on the floor costs more per week than discovery conducted over video, and it is consistently cheaper per project. The reason is that the exceptions — which are the specification — are invisible to people who have normalised them and obvious to someone watching the work happen.
Distance also shapes the build phase: an engagement inside a two-hour drive supports continuous presence, while one across the country becomes scheduled visits. Both work. They are not the same cost, and the difference should be in the plan rather than in a change request.
Measure yours in a week
These five are all countable before anyone quotes:
- List the steps a packaged product could not do without customisation. Not features — steps in a process.
- Count the integrations, marking which are two-way and which have a real, documented interface today.
- Profile a real data extract: duplicate rate on item, vendor and customer masters matched on description rather than code; null rate in fields the new system will require; whether opening stock reconciles to the ledger today.
- Name the modules for phase one, and check each against "is this currently running on a spreadsheet".
- Decide the on-site pattern and say so in the brief.
Five answers. They will change an estimate more than any negotiation will, and they belong to you regardless of who builds.
What a fixed-price discovery is buying
Our discovery phase is fixed-price and typically four to eight weeks, and it exists precisely because the five variables above cannot be assessed from a brief. It ends in process maps, testable requirements, a target architecture and a costed phased plan — written to be buildable by any competent firm.
Roughly one in six discovery clients takes that plan elsewhere. That is the arrangement working as intended: the document is worth what it cost whether or not we build, and a discovery that only has value if it converts is a sales process wearing a deliverable's clothes.
The short version
Process variance, integration surface, data condition, module count, and on-site access. Measure those five and any competent firm can price the work. Skip them, and every number you are given — including a low one — is a guess that will be revised.