Why nobody quotes a figure
Two identical-looking projects differ by three times.
Same industry, same headcount, same list of modules on the proposal — and one build is three times the other. The difference is never in the module names. It is in the number of distinct screens behind each one, the rules those screens have to enforce, and how many other systems have to be kept in agreement.
That is why the pages you have already read give you a range and stop. The range is real; it just does not help, because the range spans your project and somebody else’s at ten times the scope. What helps is knowing which levers your own project is pulling.
There are four of them, and you can estimate all four before you talk to anybody.
What moves the price
Four levers, and you can read all four yourself.
How many modules, and how deep
A module is not a unit of work — it is a label. Stock issue at one stores window is a handful of screens and two rules. Job costing across three plants with material going out to subcontractors and coming back part-consumed is the same word on a proposal and roughly ten times the work. What sets the number is the count of distinct screens and the count of rules behind them, so the scope conversation is about screens and rules rather than about module names.
How many systems it has to talk to
Every integration is a project inside the project. Biometric readers, a weighbridge, barcode scanners, Tally, the GST e-invoice portal, a bank statement feed, an existing website — each one has its own format, its own failure modes and its own retry behaviour when the other side is down. Integrations are usually where an estimate goes wrong, because they look like a line item and behave like a module.
How much of the old data has to come across
Migration cost is set by how trustworthy your existing records are, not by how many of them there are. A masters file with ten years of duplicate item codes has to be cleaned before it moves, and only your people can decide which of four similar codes is the live one. Opening balances plus the history you actually query is cheap. Eight years of line items nobody opens is cost with no benefit attached.
How many people have to be trained, and where they are
Forty people on one shift in one building is a different rollout from three plants on rotating shifts, even with identical software. Training, parallel running and the on-site week at go-live scale with headcount and with geography, and they are real line items rather than something thrown in. This is also why a quote given before anyone has seen the floor is guesswork: nobody has counted the people yet.
What the alternatives cost
The numbers a build gets compared against.
These are published prices for packaged ERP in the Indian market as of 2026 — other vendors’ figures, not ours, collected so the comparison can be made honestly. Treat them as the opening bid rather than the total: the customisation line is the one that moves most.
| Model | Typical range | What it does not include |
|---|---|---|
| Packaged cloud ERP, per user | ₹8,000 – ₹15,000 per user per year | A 20-user operation is ₹1.6–3 lakh a year in licences alone, before manufacturing modules, which are commonly quoted at a further ₹30,000–50,000. |
| Packaged ERP, flat licence | ₹2 – ₹4 lakh per year | Odoo Enterprise and similar. Flat regardless of user count, which makes it the cheaper shape once headcount is high. |
| Customisation on SAP or Oracle | ₹5 – ₹20 lakh per module | Paid on top of the subscription, and re-tested or rewritten at every major vendor version, because the vendor does not maintain your customisation. |
| Full packaged ERP deployment, manufacturing SME | ₹4 – ₹15 lakh, year one | Licence, implementation partner, customisation and training together. Annual cost continues after year one. |
Ranges compiled from Indian ERP vendor and reseller pricing published in 2026. They move, and they are averages across industries — read them as orders of magnitude, not as quotes.
The costs that arrive later
Four line items that are missing from the first quote.
The customisation you were told you would not need
The most common way an Indian manufacturer's ERP budget doubles is that the standard package turns out not to fit, and the customisation is bought anyway — after the licence is signed, at the implementation partner's rate, from a position with no leverage. The test to apply before signing: take the one process that earns your margin and ask the demo to run it end to end. If the answer involves a spreadsheet kept alongside, you have found the gap and you will be paying to close it.
The second version of the truth
This one never appears on an invoice and is usually the largest. When software does not fit the floor, the floor keeps its register and the software gets updated afterwards — so there are now two numbers for one thing and somebody's month-end is spent reconciling them. Priced as a salary, that is a recurring annual cost larger than most licence lines, and it is the cost an ERP was bought to remove.
Annual maintenance, renewals and per-user creep
Compare over five years, not one. A per-user licence grows with headcount whether or not the new people need the system, and support contracts are typically 18–22 per cent of licence value annually. A build has a maintenance cost too — it is not zero and anybody telling you otherwise is selling — but it is hours you commission rather than a percentage you owe.
The rollout that never finished
Gartner puts more than 70 per cent of ERP implementations as failing to meet their original goals. The money in a failed rollout is not the licence, it is the two years of half-migrated operation: two systems running, neither trusted, and the paper trail back in use beside both. This is the risk that a first module in real use within weeks is designed to cap — being wrong then costs one module.
Whether any of that applies to you comes down to one question, which we have written up separately: does the process that earns your margin fit the package as sold? If it does, buy the package — that is the cheaper answer and you will hear it from us. If it does not, no amount of configuration closes the gap and the customisation line is where your budget goes.
How we price it
A week, then a fixed number for one module.
Discovery runs for a week, on your premises — the plant floor, the stores window, the counter where fees get collected. It ends with a written scope and a fixed price for the first module: one number, not a range, and not subject to revision unless you change the scope. That module is chosen to be small enough that being wrong about it is survivable and useful enough that you would want it even if nothing else followed.
You commit to that and nothing beyond it. Every module after the first is quoted the same way, so the price you are asked to approve is always for work somebody has already thought through — and a project that stops leaves you holding working software rather than a half-configured tenant and an annual licence.
Our office is in Trichy, Tamil Nadu, and we work with organisations across India. Discovery and go-live happen in your building; the build between them is remote.
Questions about money
The answers before the first call.
So what will our project cost?
We do not publish a rate, and the reason is not coyness. A figure quoted before anyone has walked your floor is guesswork with a decimal point on it, and the two projects that look identical on paper — same industry, same headcount, same module list — routinely differ by a factor of three once somebody has stood at the stores window and watched an issue actually happen. What we commit to instead is this sequence: a week of discovery on your premises, at the end of which you get a written scope and a fixed price, a single number rather than a range, for the first module. That module is deliberately small enough that being wrong about it is survivable and useful enough that you would want it even if nothing else followed. You commit to that and to nothing beyond it. If the price and the problem do not meet, you have spent a week finding out rather than six months and a signed annual licence.
Is a custom ERP cheaper than buying one?
Over one year, usually no. Over five, frequently yes, and the honest answer is that it depends on a single test we will apply in week one rather than on a general preference for building. If something you can buy already covers roughly 80 per cent of how you work, buy it, configure it, and have the remaining 20 per cent built around it — that is cheaper, faster and easier for your own people to keep running, and it is the recommendation you will get from us when it is true. Custom becomes the cheaper option when the process that earns your margin is precisely the part nothing on the market handles, because then the package's price is only its opening bid: you pay the licence, then the customisation at ₹5–20 lakh a module, then the licence again next year, and you still do not own the thing you paid to have built. The comparison that matters is five-year total cost against a system that fits, not year-one licence against year-one build.
How do you price the work — fixed, hourly, or per module?
Fixed price per module, scoped one module at a time. Each module is quoted as a single number after its scope is written down, and that number does not move unless you change the scope, in which case the change is quoted before it is built rather than invoiced after. We do not work on an open hourly meter for build work, because an hourly meter puts the risk of a bad estimate on you and removes our incentive to be right about it. We also do not quote the whole system as one fixed price up front, which sounds like the safer arrangement and is the opposite: a single price for a system nobody has scoped yet is priced for the worst case, and the worst case is what you pay whether or not it happens. Scoping module by module means the price you are asked to approve is always for work somebody has actually thought through.
What does it cost to run once it is live?
Three things, all of them yours and all of them visible. Hosting is the first: a cloud account in your company's name, billed to you directly rather than marked up through us, which for an operation of a few dozen users is typically a small monthly figure rather than a licence-sized one — and if you would rather run it on a server in your own building, that works too. The second is whatever statutory and integration maintenance the system needs: GST formats change, e-invoice schemas get revised, a reader firmware update breaks a punch export. That is real ongoing work and we quote it as hours you commission rather than as a percentage of anything. The third is changes you want, which is not a maintenance cost at all — it is new work, priced the same way the original modules were. There is no licence, no per-user fee and no retainer you cannot end.
What happens to the cost if we want to stop halfway?
You stop, you owe nothing beyond the module in progress, and what has been built keeps working. This is a direct consequence of how the work is scoped rather than a concession: each module is quoted and paid for on its own, the code is in a repository your organisation owns from the first week, and the servers and database are in your accounts. So a project halted after two modules leaves you with two working modules, the source code for them, and a system that does not stop when we do. The comparison worth making is with a package abandoned mid-rollout, where the licence is annual and already committed, the customisation is sunk, and what you are left with is a partially configured tenant you cannot take anywhere. We would rather you stayed because the work is good than because leaving is expensive.
Do you work with a budget we already have?
Yes, and telling us the number early makes the conversation shorter rather than more expensive. A budget is a scoping constraint, and it is far more useful to us than a module wish list, because it lets us start from the other end: what is the most valuable thing that fits inside this, and is that thing worth doing on its own? Sometimes the answer is that the budget buys a genuinely useful first phase and the rest waits for it to prove itself, which is roughly how we would sequence the work anyway. Sometimes the answer is that the budget does not reach the problem as described, and you will hear that in week one rather than discovering it at 60 per cent complete. The version of this that goes badly is a budget kept quiet, a scope agreed to fit it on paper, and the gap surfacing as change requests later.
Tell us the scope and the budget.
What you do, how many people would use it, what it has to talk to, and the number you have. That is enough for us to say whether the budget reaches the problem — and if it does not, you will hear that rather than a scope written to fit it on paper.