Custom ERP or off-the-shelf: one test decides it.

Take the one process that earns your organisation its margin, and ask a demo to run it end to end, with your own awkward case in it. Not the tidy version: the job that goes out to a subcontractor and comes back part-consumed and part-rejected while the job is still open, or the lot split across two machines, or the customer variant that changes the routing without changing the item code. Watch what the software does. If it handles it, buy the package — configure it, have the remaining edges built around it, and you will have spent less and your own people will find it easier to keep running. If the answer involves a spreadsheet kept alongside, you have found the gap, and that gap is where a register reappears on the floor and you end up with two versions of one number. The rough threshold is 80 per cent: if a product covers about 80 per cent of how you work, buy it. Below that, configuration does not close the distance and you will pay to build the difference anyway, on somebody else's terms.

They are the safe choice on software quality and the risky one on fit, and mid-sized manufacturers routinely misread which risk they are carrying. What you get is genuinely mature: the accounting is correct, the statutory returns work, the audit trail will satisfy anybody, and nobody gets criticised in a board meeting for choosing them. What you also get is a process model built from large-enterprise practice, and the distance between that and a 40-person plant with three decades of its own conventions is real. That distance is closed with customisation at roughly ₹5–20 lakh per module, which you then maintain across vendor upgrades forever, on top of a subscription that continues. Gartner puts more than 70 per cent of ERP implementations as failing to meet their original goals, and very few of those failures are because the software was bad. They are fit failures. So the question is not whether SAP works — it does — but whether your margin-earning process fits it as sold.

Almost certainly not, and we would usually argue against it. Tally is good at what it does, your accountant knows it thoroughly, and replacing a working accounting package is disruption bought at full price for a benefit nobody can name. What Tally is not is an operations system: it does not carry job cards, machine-wise output, stock movements at the point they happen, or shift-wise attendance, and every attempt to make it do so ends as a folder of spreadsheets beside it. So the usual arrangement is a division of labour. The ERP owns operations — sales orders, purchase, inventory, production, dispatch, payroll — and posts into Tally what accounting actually needs, so nobody keys a voucher twice and the two systems cannot disagree about a number. If you genuinely want off Tally, that is a scoped migration with a cut-over plan and a parallel-running month, priced as its own piece of work rather than smuggled into a build.

Often yes, and it is the option most commonly skipped in a build-or-buy conversation that has already decided it is binary. Odoo in particular sits in a genuinely useful place: a flat licence of roughly ₹2–4 lakh a year regardless of user count, a module structure you can extend in code rather than only configure, and source you can read. For an operation whose process is 70-something per cent standard, extending Odoo is frequently cheaper than either buying SAP or building from nothing, and we will say so. The catch is the one everybody underestimates: an extended open-source ERP is a custom system, with custom-system maintenance, upgrade pain and the need for somebody who understands it — you have changed who does the work, not whether the work exists. Where it stops being the answer is when your core process fights the framework's data model, because then every extension is working against the grain and you are paying twice.

Make the first commitment small enough that being wrong about it is survivable, and make it verifiable against something that already exists. In practice that means one narrow process — attendance, stock issue, job cards, fee collection — put into real daily use at the counter or the machine it belongs to, while everything else carries on unchanged. For the first month it runs beside whatever you do today, so the two can be compared at close and nobody is asked to trust a screen over a register they have kept for fifteen years. That module is the honest test of the partner as much as the software: it either survives a month of people using it under pressure or it does not, and finding out in week six costs you one module. Alongside that, insist on three things from day one — the repository under your organisation's account, the cloud accounts billed to you, and the runbook written as the work happens. If those are in place, the project can survive losing the people who built it.

Because the alternative is worse for us, not just for you. A build sold to an organisation a package would have served spends six months proving that, and what it produces is a client who is unhappy for reasons they cannot quite articulate, a reference we cannot use, and a system somebody else eventually replaces. We are a small team taking few projects at a time, so a bad fit does not average out across a portfolio — it occupies a slot we cannot get back. The self-interested version of honesty is simply that we would rather spend a discovery week finding out and say so. In practice this happens: the answer that the package fits, or that extending Odoo is the cheaper route, or that the real problem is one internal tool rather than an ERP at all. You are welcome to take that answer and act on it without us.