ERP that holds when the organisation is big.

Ortix Labs is a software studio in Trichy, Tamil Nadu that builds large-scale ERP systems and the internal platforms around them, for manufacturers, educational institutions and multi-branch operations. We build to order. We do not sell a product and then fit the organisation to it. A project runs in four stages: a week of questions on your premises before any code is written, one narrow module put into real daily use, then hardening — tests, monitoring, runbooks, backups that have actually been restored from — and finally a handover your own team can work from. The range runs from a full ERP carrying orders, stock, production, purchase, people and money, down to a single internal tool that retires one spreadsheet. We are a small team, which is why we take few projects at a time and own the whole path to production on each of them rather than a slice in the middle.

An ERP system is one place where the work an organisation actually does is recorded — orders, stock, production, purchase, admissions, fees, people, money, and the approvals between them — so the same number is not kept in four places and reconciled by hand at month end. In practice it means a goods receipt moves stock, costing and payables at the same moment, rather than being written into three registers by three people who each believe theirs is the correct one. The hard part is rarely the software. It is that every organisation's real process differs from the one a product assumes: the job sent to a subcontractor that comes back part-consumed, the fee concession approved verbally, the branch that has always done it its own way. That distance between the documented process and the real one is where the spreadsheets come back, and it is where most of the interesting work in a build actually sits.

Often a product will do, and we would rather say so in week one than have you discover it in month six. The test is straightforward. If something you can buy already covers around 80 per cent of how you work, buy it, configure it, and have the remaining 20 built around it — that is cheaper, faster, and easier for your own people to keep running afterwards, and it is the recommendation you will get from us when it is true. Custom is the right answer when the process that earns the organisation its money is precisely the part nothing on the market handles. The wrong reason to build is that a demo felt unfamiliar. The wrong reason to buy is that a licence looked cheaper than a build, because that cost arrives later, as workarounds nobody budgeted for.

Manufacturing and engineering, educational institutions, distribution and multi-branch retail. What they share is not a sector, it is a shape: a process that is specific to the organisation, several people who each hold a piece of it, and a month-end that is assembled rather than read off. A pump manufacturer's routing problem and a college's fee-concession problem look nothing alike from outside and are the same problem underneath — a rule that lives in somebody's head and has to be made explicit before software can carry it. We are equally willing to say a project is outside what we do. Work that is mainly data science, game development or device firmware is not ours, and hearing that on the first call costs you an hour instead of a quarter.

Yes — we work with organisations anywhere in India. The office is in Trichy, Tamil Nadu, postcode 620020, and that is where the team sits. The parts that need us in the building happen in the building: the first week of questions, walking the floor or the campus, and go-live week. Everything between those is remote, against a fixed weekly call and something you can open and click at the end of every one of them, so distance never becomes the reason a project goes quiet for a month. For clients further away we travel in planned blocks and name those weeks at the start rather than promising to appear. The one arrangement that does not work is a project needing somebody at your desk daily. That is a staffing contract rather than a build, and it is not what we do.

Weeks for the first working module, not a year for the whole system. We pick the narrowest thing that is useful on its own and can be checked against something that already exists — attendance, or stock, or fee collection — and put it into real daily use while everything else carries on unchanged. That module is the honest test of the project. It either survives a month of people using it under pressure or it does not, and if it does not, that is a cheap thing to have learned in week 6 rather than an expensive thing to discover in month 9. Everything afterwards is widening a system that already works instead of guessing at one that might. We will not give you a date for the full rollout before the discovery week, because a date set before anyone has read the scope is a number chosen to win a meeting.

You do, all of it, from the first commit rather than from the final invoice. The source code sits in a repository under your organisation's account, the servers and databases run in cloud accounts billed to you, and the documentation, credentials and deployment steps are written during the work rather than sold back at the end of it. Nothing of ours sits in the middle of the system waiting to stop working if the relationship does. We would rather you stayed because the work is good than because leaving is expensive, so there is no lock-in and no retainer you cannot end. In practice the test is this: a developer you hire, or another firm entirely, should be able to read the repository, run it on their own machine and carry on. If they cannot, the handover is not finished, and finishing it is our job.

The honest answer is that it depends on scope, and the useful answer is what the scope is made of, so here is the arithmetic rather than a figure. A build is priced per module, and a module is priced by how many distinct screens it needs, how many rules sit behind them, and how many systems it has to talk to. A stock-issue module for one stores window is a different quantity of work from job costing across 3 plants with subcontracting in the middle, even though both are one line on a proposal. For market context, packaged ERP in India generally runs ₹8,000–₹15,000 per user per year on a per-user licence, or ₹2–4 lakh a year flat on a model like Odoo's, before the customisation that most manufacturers end up buying anyway — and customisation on SAP or Oracle is commonly quoted at ₹5–20 lakh per module. Those are the numbers a build gets compared against. We publish no rate card, because a price quoted before anyone has walked your floor is guesswork with a decimal point on it. What we do commit to is a fixed price, not a range, for the first module at the end of the discovery week. We have written the cost mechanics up in full on a separate page.

Yes, and in most projects Tally stays exactly where it is. GST-compliant invoicing, e-invoice generation against the IRP and e-way bills are a solved problem with published APIs — we treat them as a compliance requirement to be met rather than a feature to be marketed, which is the right framing because getting them wrong is a penalty rather than an inconvenience. Statutory formats change, so that part of the system is written to be updated when they do, not hard-coded to this year's schema. On Tally specifically: replacing a working accounting package is rarely worth the disruption, and your accountant knows it well. The usual arrangement is that the ERP owns operations — orders, purchase, inventory, production, dispatch, payroll — and posts what accounting needs into Tally, so nobody keys a voucher twice and the two never disagree about a number. If you would rather migrate off Tally entirely, that is a scoped piece of work with a cut-over plan, not a switch we flip quietly during a build.

In stages, with a way back at every stage, and never as a single overnight switch. The first step is not technical: we find out which of your existing records are actually trusted. In practice a masters file — items, customers, suppliers, BOMs — has accumulated 10 years of duplicates, dead codes and one-off entries, and migrating it faithfully means importing the mess and then blaming the software for it. So masters get cleaned before they move, by your people, because only they can tell which of 4 similar item codes is the live one. Transactional history is different: we move opening balances and whatever depth of history you genuinely query, not everything, because 8 years of line items nobody opens is cost without benefit. Each module runs in parallel with what it replaces for about a month, and the two are reconciled at close before the old one stops. If the numbers do not agree, the old system is still running and nothing has been lost, which is the entire point of doing it this way.