Decide what you are actually buying, before any demo
The single most common mistake is starting with product research. You end up comparing feature lists, every vendor ticks every box, and the decision defaults to price or to whoever demoed most confidently.
Write down instead the three things going wrong now that cost real money or real hours. "Stock on the system is wrong so we over-order." "Field orders get typed twice and mistakes reach the customer." "Month-end takes nine days." Those three sentences are your specification, and anything a product does that does not touch them is not a reason to buy it.
What to check, in order
- Does it solve your three problems? Not "does it have the module" — does the actual screen sequence solve your actual problem.
- Indian statutory fit GST invoicing, e-invoice IRN, e-way bill, TDS, and payroll deductions if you run payroll. Ask to see one generated, not a slide about it.
- Who does the data migration, and who pays for it. This is where implementations fail and where quotes hide money.
- What happens after go-live who answers the phone, in what hours, and what the response commitment is.
- Total annual cost for three years, including users you will add and modules you will switch on later.
- How you get your data out if you leave. Ask before you sign, not after.
Insist on a demo with your own documents
A standard demo is a rehearsed route through a clean database. It tells you almost nothing, because every product looks good on data designed to make it look good.
Send one month of your own paperwork — a few purchase orders, a few invoices, your item list with its awkward units and half-duplicate names — and ask them to show that. You will learn more in twenty minutes than in three polished demos, and you will find out early whether the vendor is willing to do it.
Questions that separate vendors
- "What does your product do badly?" A vendor with no answer is either inexperienced or not being straight with you.
- "Which of my three problems does it not solve?"
- "Show me a customer like us who stopped using it, and why."
- "What is not included in this price?"
- "If we sign today, what do you need from us, and when will it actually be live?"
How to weigh open source
Open-source ERPs such as ERPNext are genuinely free to licence and can be self-hosted at the cost of a server. That is a real advantage, not a catch. The cost is that somebody has to host it, upgrade it, keep add-on apps compatible, and be accountable when something breaks during a GST filing week.
If you have that person, open source is often the best value available to an Indian SME. If you do not, what you are buying from a commercial vendor is that nobody on your team has that job — which is a legitimate thing to pay for, and should be priced as such rather than dressed up as a feature.
A short shortlist beats a long one
Three products is enough. More than that and the evaluation itself becomes the project, and the comparison sheet starts driving the decision instead of your three problems.
Run each against the same month of your own documents, in the same room, with the same people. Then pick the one whose answer to "what do you do badly" you can live with.
In short
- Write down three operational problems before looking at any product.
- Demo with your own documents; a clean-database demo proves nothing.
- Ask what the product does badly. The answer, or its absence, is information.
- Price three years, not one, including users and modules you will add.
- Open source is genuinely cheaper only if you have someone to run it.