ERP implementation, integration and the work around it
A platform ERP is a good decision for a lot of businesses and a quietly expensive one for the rest. The work that decides which is not the licence - it is the configuration, the integrations, and what you do about the parts that do not fit.
Whether to implement it at all
The first question is not which platform. It is how much of your process the platform assumes, and whether those assumptions are ones you can live with. Zoho, Odoo and NetSuite each encode a default way of running a business. Where that default matches you, you get years of someone else's engineering for a licence fee. Where it does not, you get a customisation backlog that never empties.
We will map your process against the platform's model before anyone signs anything, and tell you plainly where the friction will be. Sometimes the answer is that the platform fits and the project is a configuration exercise. Sometimes it is that two departments fit and one does not, and the right build is the platform plus a custom module beside it. Occasionally it is that you should not buy it.
That conversation is worth having with someone who has no licence revenue riding on the answer.
Configuration, data, integration, handover
Implementation is four jobs. Configuring the platform to your chart of accounts, tax treatment and approval chains. Migrating data that is almost never as clean as anyone claims - the duplicate vendor records, the three spellings of the same customer, the stock balances that do not tie out. Building the integrations to whatever else you run. And training the people who will use it daily, which is the part most often cut and most often fatal.
The integrations are usually where the real engineering is. A platform ERP talks to your e-commerce storefront, your payment gateway, your logistics partner, your bank statements and your GST filing, and each of those connections has failure modes that matter: a webhook that fires twice, a payout file that arrives in a different column order, a rate limit that silently drops the last hour of orders. We build these to be re-runnable and to tell you loudly when they break, rather than to work on a good day.
GST, e-invoicing and TDS are not afterthoughts in an Indian implementation. They constrain the data model, and retrofitting them after go-live is painful.
Extending instead of bending
Every implementation reaches a workflow the platform will not do cleanly. The usual instinct is to force it with custom fields and scripts until the configuration is a program nobody can read, held together by one person's memory.
The better move is often to let the platform do what it is good at and build the awkward workflow properly beside it, talking to the ERP through its API. The custom piece stays small, readable and testable; the platform stays close to stock, so it can still be upgraded. We build both sides of that line and are candid about where to draw it.
If a migration off a platform is what you actually need, that is a custom ERP project and we would scope it as one.
We work out of Ghatkopar East in Mumbai. Implementation work starts with time on site wherever you are, because the fit assessment is worth nothing done over a call, but being in Mumbai means most of that is a train ride rather than a flight.
What ships with the build
- 01
A fit assessment before the licence
Your process mapped against the platform's assumptions, with the friction named before you commit.
- 02
Data migration that reconciles
Duplicates, inconsistent masters and stock that does not tie out - found and resolved before go-live, not after.
- 03
Integrations built to fail loudly
Re-runnable syncs with real error reporting, so a dropped hour of orders surfaces immediately instead of at month end.
- 04
GST and e-invoicing in the model
Indian tax treatment designed in at the start, where it constrains the schema, rather than retrofitted afterwards.
- 05
Extensions that stay upgradeable
The awkward workflows built beside the platform through its API, so the core stays close to stock.
Questions we are actually asked
We are an independent software studio, not a reseller, and we do not take licence margin from any vendor. That means we have no commercial reason to recommend one platform over another or to recommend buying at all. If you want a badged partner for procurement reasons we will say so plainly and work alongside one.
It depends on where your complexity sits. Zoho is strong when your processes are close to its defaults and you want the surrounding suite. Odoo gives you more room to modify, at the cost of owning those modifications. NetSuite is built for larger, multi-entity operations and priced accordingly. Anyone who answers this question without first looking at your process is selling you something.
Often, yes. The usual pattern is a configuration that has drifted into an unreadable program, integrations that fail silently, and a team that has quietly gone back to Excel. We start by finding out which of the three is actually hurting, because the fix for each is different and doing all three at once is how these projects stall twice.
By assuming the data is dirty, because it always is. Masters get de-duplicated and reconciled first, opening balances are tied out against your accounts, and the whole migration is run end to end in a staging environment before anyone goes live. You see the reconciliation report before we cut over, not after.
Then we build that workflow beside it rather than forcing it inside. The custom piece talks to the ERP through its API and stays small enough to read and test, and the platform stays close to stock so it can still be upgraded. Forcing it in is what produces a system nobody can safely change.
Tell us what you are trying to build.
A short first conversation, no deck. If we are the wrong studio for it we will say so and point you somewhere better.