ERP software development for organisations that outgrew the product.

It builds the single system an organisation records its real work in — orders, stock, production, admissions, fees, people, money and the approvals between them — so the same figure is not kept in four places and reconciled by hand at month end. The build itself is the smaller half. The larger half is finding out how the organisation truly works, which is rarely what the process document says, and then designing a system that carries that honestly instead of demanding everyone work the product's way. That is also the line along which firms differ, and it is worth establishing which kind you are speaking to before you compare prices. Some sell a licence and call the configuration an implementation. Some supply developers by the month and leave the architecture to whoever is available on your side. Some take the whole path — discovery, architecture, build, hardening, handover — and are answerable for whether the thing survives its first month-end. All three will quote on the same enquiry. They are not quoting on the same work.

Both, and you should be wary of any firm whose answer is always the same one, because the right answer depends on your process rather than on who is free on their bench. A firm that only implements a licensed product will find a way for your process to become the product's process. A firm that only writes code will find a reason to write code. Our rule: where a package already covers most of the ground, it should be bought and extended, and we will say so on the first call even when it costs us the work. We write a system from the ground up when the part that earns the money is the part packages handle worst, or when licence and per-user fees over 5 years exceed what building it once costs. A useful question for every vendor on your shortlist is not which they recommend, but when they last recommended the other one.

On a fixed rhythm rather than on goodwill. We are in Trichy, Tamil Nadu, and a client in Pune or Kochi or Delhi works the same way as one an hour away: a call at the same hour every week, and at the end of each one something deployed that you can open and use rather than a percentage on a status sheet. Scope in writing, decisions in writing, and a record of what changed, so the project survives the person who attended those calls moving on. Two points are on your premises regardless of the map. Discovery, because a job card or a fee structure cannot be designed from a video call. And go-live, because that is the week the questions arrive from people who were in none of the meetings. Travel is planned into the schedule and the weeks are named up front. A resident engineer is the one thing we will not promise.

The first working module reaches daily use in weeks. The full system depends entirely on how much of the organisation it covers, and a firm quoting a duration before the discovery week is guessing at your expense. When you compare proposals, look closely at what each one means by go-live. A single date on which every department switches at once is the arrangement that produces the ERP stories you have already heard: a quarter of parallel running, a quiet return to the old registers, and a system nobody trusts a year later. We sequence instead. The first module to go live is one whose output can be audited against a record that already exists, so it is either right or visibly wrong within a month. The next begins from something proven. A phased schedule looks slower drawn on a chart and finishes sooner, because nothing has to be unwound.

That is usually a large part of the job, and it belongs in the first meeting rather than the fifth. Most organisations we speak to run accounting in Tally or something like it, have one licensed system that covers a single department well, and hold a decade of history in spreadsheets that are load-bearing whether or not anyone will admit it. None of that has to be discarded. We read from and write to what exists through whatever it exposes — an API, a database, a scheduled file — and history moves in stages, each with a way back, rather than in one overnight cutover with no reverse gear. The standard we hold to is that nobody in the building retypes a figure that already exists somewhere else in it. Where an existing system genuinely cannot be integrated, you will hear that before you are committed instead of afterwards.

We do not publish a number, because a number without a scope is a guess dressed up as a quote. What we do is fix the price of the first working module after the discovery week, so you buy something real for a known cost before committing to anything larger. When you set our quote beside others, compare what sits inside each one. Whether licences and per-user fees are included or arrive every year afterwards. Who pays for hosting. Whether data migration and training are line items or assumptions. What happens to the price when scope moves, because it will move. A quote that is lower because it quietly excludes migration is not lower. Ask as well what support costs in year 2, once the discount that won the deal has expired. If your budget and the problem do not meet, that surfaces here in week 1 instead of month 6.

You take everything with you and nothing of ours has to be bought out first. The repository lives in your organisation's account, the infrastructure runs in cloud accounts billed to your company, and the architecture notes, runbooks and deployment steps are produced during the build rather than assembled as a favour at the end of it. No licensed component of ours sits inside the system, so there is nothing to place in escrow and no renewal that can be used as leverage in a negotiation. What actually makes a system portable is not a clause but whether the next engineer can read it, so the work uses mainstream tooling a competent team already knows, and the documentation is written for somebody who was never in the room. Any firm will promise you ownership on paper. The better question is what a replacement would have to install to run it.

Tell us 3 things: what the organisation does, how the month closes today, and the one process that costs the most time or causes the most arguments. That is enough for us to say whether you are looking at a focused build of one or two modules or a bigger structural problem, whether the honest answer is a package rather than a project at all, and whether we are the right team either way. There is no deck and no fee attached to that conversation. If it goes further, the next step is a week on your premises with the people who do the work rather than only the people who authorise it, ending in a written scope and a fixed price for the first module. Write to hello@ortixlabs.com with that much and you will get questions back rather than a brochure.